Tasarım Kalıpları — Ne Zaman Kazandırır

Kalıp öğrenmenin en yaygın yan etkisi, her yerde uygulanacak yer aramaktır. Oysa kalıplar icat edilmedi — fark edildi. Farklı ekipler aynı probleme aynı çözümü bulunca ona bir ad verildi.

Kalıp sana iki şey verir

Bir kalıp sana iki şey verir: bir ad ve bir takas.

Ad, iletişim aracıdır. “Burada Strategy var” demek, karşı tarafa on satırlık açıklama yapmaya bedeldir — ama yalnızca o da adı biliyorsa.

Takas, asıl konudur. Hiçbir kalıp maliyeti yok etmez; bir yerden alıp başka yere koyar.

Strategy yeni tip eklemeyi ucuzlatır ve tüm tiplere yeni işlem eklemeyi pahalılaştırır. Bu, kalıbın kusuru değil, tanımıdır.

Gerçekten işe yarayan birkaçı

Yirmi üç kalıbı ezberlemek gereksiz. Günlük işte tekrar tekrar karşına çıkan birkaçı var:

Adapter ile Facade sık karıştırılır: Adapter şekli değiştirir, Facade yüzeyi küçültür. Adapter’da karşı taraf zaten doğru işi yapıyordur, imzası uymuyordur; Facade’da işler doğrudur ama çağıranın görmesi gereken çok fazla şey vardır.

Satır satır: switch ne zaman Strategy’yi hak eder

Bu takasın adı expression problem?Terimin tanımını açexpression problemBir tasarımın ya yeni tip eklemeyi ya yeni işlem eklemeyi ucuzlatabilmesi, ikisini birden ucuzlatamaması.Polimorfizm yeni tipi ucuzlatır: yeni sınıf yazarsın, çağıran değişmez. switch ise yeni işlemi ucuzlatır: tek yerde tüm tipleri ele alırsın. Hangisinin daha sık olacağını bilmek, kalıp kararını verir.Sözlükte gör →: polimorfizm yeni tip eklemeyi ucuzlatır, switch yeni işlem eklemeyi. İkisini birden ucuzlatan bir tasarım yok.

Bir bankada para gönderirken de aynı soru çıkar: FAST mı, EFT mi, SWIFT mi? Gel, her kanalın kendi dosyasında yaşadığı küçük bir örneğe bakalım.

1
public interface TransferRail {
2

3
    Rail rail();
4

5
    // Adding a method here opens every rail class: the price of this pattern.
6
    TransferResult send(OutgoingTransfer transfer);
7
}

1
@Component
2
final class FastRail implements TransferRail {
3

4
    private final FastClient client;
5
    private final BigDecimal maxAmount;   // per-transfer ceiling set by the central bank
6

7
    FastRail(FastClient client, @Value("${rails.fast.max-amount-try}") BigDecimal maxAmount) {
8
        this.client = client;
9
        this.maxAmount = maxAmount;
10
    }
11

12
    @Override
13
    public Rail rail() {
14
        return Rail.FAST;
15
    }
16

17
    @Override
18
    public TransferResult send(OutgoingTransfer transfer) {
19
        if (!transfer.amount().currency().equals(Currency.getInstance("TRY"))) {
20
            throw new IllegalArgumentException("FAST carries TRY only");
21
        }
22
        if (transfer.amount().value().compareTo(maxAmount) > 0) {
23
            throw new IllegalArgumentException("amount above FAST limit");
24
        }
25
        return client.submit(transfer.debtorIban(), transfer.creditorIban(), transfer.amount().value());
26
    }
27
}

1
@Service
2
public class TransferDispatcher {
3

4
    private final Map<Rail, TransferRail> byRail;
5

6
    // Spring injects every TransferRail bean; a new rail is a new @Component, nothing more.
7
    TransferDispatcher(List<TransferRail> rails) {
8
        this.byRail = rails.stream()
9
                .collect(Collectors.toUnmodifiableMap(TransferRail::rail, Function.identity()));
10
        // toUnmodifiableMap throws on a duplicate key, so two beans for one rail fail at startup.
11
    }
12

13
    public TransferResult dispatch(OutgoingTransfer transfer) {
14
        TransferRail rail = byRail.get(transfer.rail());
15
        if (rail == null) {
16
            throw new IllegalStateException("no rail registered for " + transfer.rail());
17
        }
18
        return rail.send(transfer);
19
    }
20
}

1
// The switch version: perfectly fine while the rails stay few and fixed.
2
@Service
3
public class SwitchTransferDispatcher {
4

5
    private final FastClient fast;
6
    private final EftClient eft;
7
    private final SwiftGateway swift;
8

9
    SwitchTransferDispatcher(FastClient fast, EftClient eft, SwiftGateway swift) {
10
        this.fast = fast;
11
        this.eft = eft;
12
        this.swift = swift;
13
    }
14

15
    public TransferResult dispatch(OutgoingTransfer t) {
16
        // Every rail is wired here; a new rail means editing this tested method.
17
        return switch (t.rail()) {
18
            case FAST -> fast.submit(t.debtorIban(), t.creditorIban(), t.amount().value());
19
            case EFT -> eft.submit(t.debtorIban(), t.creditorIban(), t.amount().value());
20
            case SWIFT -> swift.sendMt103(t.debtorIban(), t.creditorIban(), t.creditorBic(), t.amount());
21
        };
22
    }
23
}

Kendin gör

Sırayla dene:

1. Başlangıçta tek switch var. “Eklenecek yeni kanal”ı 2’ye indir — en ucuz tasarım hangisi?
2. Kanalı 12’ye çıkar. Şimdi registry kazanıyor: kalıp kendini ödemeye başladığı nokta burası.
3. Kanalı 12’de bırakıp “yeni işlem”i 8’e çıkar. Kazanan yine switch — expression problem’i sayılarla görüyorsun.
4. “Kalıp yığ”a bas ve tabloyu incele: hiçbir karışımda kazanmıyor. Bir kalıp takas yapmıyorsa sadece dolaylılık?Terimin tanımını açdolaylılıkBir şeye doğrudan değil, araya giren bir katman üzerinden ulaşmak. Esneklik verir, okurken bir adım daha attırır — bedava değildir.Sözlükte gör → ekliyor demektir.

Tuzaklar

Singleton. Kalıp listesindeki en popüler ve en zararlı madde: global durum yaratır, testte izole edilemez, bağımlılığı imzada gizler.

Bugün ihtiyacın olan şey neredeyse her zaman “tek örnek”tir, “global erişim” değil — onu da DI container zaten veriyor.

Kalıp önce, problem sonra. Tasarıma “hangi kalıbı kullansam” diye başlamak, çözümü probleme uydurmaktır. Doğru sıra: değişim nereden gelecek, sonra hangi takas.

İsimlendirme kargaşası. OrderStrategyFactoryImpl gibi adlar kalıbı anlatır ama işi anlatmaz. Sınıf adı ne yaptığını söylemeli; kalıbın adı gerekiyorsa yorumda durabilir.

Kendini sına