CEN206 Nesne Yönelimli Programlama¶

Hafta-12 (Kod Kokuları ve Yeniden Yapılandırma Temelleri)¶

Bahar Dönemi, 2025-2026¶

İndir DOC-PDF, DOC-DOCX, SLAYT

Kod Kokuları ve Yeniden Yapılandırma Temelleri¶

İçerik¶

• Modül A: Yeniden Yapılandırma Nedir? -- Tanım, Temiz Kod, Teknik Borç, Ne Zaman Yeniden Yapılandırılır, Nasıl Yeniden Yapılandırılır
• Modül B: Şişkinler (Bloaters) -- Uzun Metot, Büyük Sınıf, İlkel Takıntı, Uzun Parametre Listesi, Veri Kümeleri
• Modül C: Nesne Yönelim Kötüye Kullananlar (OO Abusers) -- Switch İfadeleri, Geçici Alan, Reddedilen Miras, Farklı Arayüzlere Sahip Alternatif Sınıflar
• Modül D: Değişim Engelleyiciler (Change Preventers) -- Iraksak Değişim, Saçma Ameliyat, Paralel Kalıtım Hiyerarşileri
• Modül E: Gereksizler (Dispensables) -- Yorumlar, Tekrarlanan Kod, Tembel Sınıf, Veri Sınıfı, Ölü Kod, Spekülatif Genellik
• Modül F: Bağlayıcılar (Couplers) -- Özellik Kıskançlığı, Uygunsuz Yakınlık, Mesaj Zincirleri, Aracı

İçerik (Devamı)¶

Kapsanan Tüm 22 Kod Kokusu¶

Kaynak: Refactoring.Guru -- Kod Kokuları

Kod Kokusu Kategorileri (Genel Bakış)¶

Modül A: Yeniden Yapılandırma Nedir?¶

Tanım, Temiz Kod, Teknik Borç, Ne Zaman Yeniden Yapılandırılır, Nasıl Yeniden Yapılandırılır¶

Modül A: Yeniden Yapılandırma Nedir? -- Tanım¶

Yeniden yapılandırma (Refactoring), kodun dış davranışını değiştirmeden iç yapısını iyileştirmenin sistematik bir sürecidir.

• Yeniden yapılandırmanın temel amacı teknik borçla mücadele etmektir
• Dağınık, kötü tasarlanmış kodu temiz, iyi tasarlanmış koda dönüştürür
• Yeniden yapılandırma, hata düzeltme veya yeni özellik ekleme değildir
• Kodu daha kolay anlaşılır, bakımı yapılabilir ve genişletilebilir hale getirmekle ilgilidir
• Bunu bir dizi küçük, davranışı koruyan dönüşüm uygulamak olarak düşünün

"Yeniden yapılandırma, mevcut bir kod tabanının tasarımını iyileştirmek için kontrollü bir tekniktir. Özü, her biri tek başına yapılmaya değmeyecek kadar küçük olan bir dizi küçük davranış koruyucu dönüşüm uygulamaktır. Ancak bu dönüşümlerin her birinin kümülatif etkisi oldukça önemlidir." -- Martin Fowler

Referans: RefactoringGuru -- Yeniden Yapılandırma Nedir

Modül A: Kirli Kod vs. Temiz Kod¶

Kirli Kod Nedir?¶

Kirli kod, okunması zor, değiştirilmesi zor ve bakımı zor olan koddur. Kısayollar, acele teslim tarihleri ve disiplin eksikliği nedeniyle zamanla birikir.

Temiz Kod Nedir?¶

Temiz kod bunun tam tersidir -- açık, bakımı kolay ve çalışması keyifli olan koddur.

"Yeniden yapılandırmanın temel amacı teknik borçla mücadele etmektir. Dağınıklığı temiz koda ve basit tasarıma dönüştürür."

İlişki¶

Kirli Kod  --[yeniden yapılandırma]-->  Temiz Kod
     |                                      |
     v                                      v
  Bakımı zor                         Bakımı kolay
  Değiştirmesi pahalı                Değiştirmesi ucuz
  Gizli hatalarla dolu               Hatalar görünür

Modül A: Temiz Kod Özellikleri¶

Temiz kod, kirli koddan ayıran dört temel özelliğe sahiptir:

1. Temiz Kod Diğer Programcılar İçin Açıktır¶

• Kötü değişken adları, şişmiş sınıflar ve sihirli sayılar kodu özensiz ve kavranması zor hale getirir
• İyi kod neredeyse iyi yazılmış bir düzyazı gibi okunur
• Diğer geliştiriciler kapsamlı dokümantasyon olmadan anlayabilir

2. Temiz Kod Tekrarlama İçermez¶

• Tekrarlanan kodda her değişiklik yaptığınızda, aynı değişikliği her örnekte yapmayı hatırlamanız gerekir
• Bilişsel yükü artırır ve ilerlemeyi yavaşlatır
• DRY (Kendini Tekrar Etme - Don't Repeat Yourself) ilkesini ihlal eder

"Tekrarlanan kodda her değişiklik yapmanız gerektiğinde, aynı değişikliği her örnekte yapmayı hatırlamanız gerekir." -- RefactoringGuru

Modül A: Temiz Kod Özellikleri (Devamı)¶

3. Temiz Kod Minimum Sayıda Sınıf ve Hareketli Parça İçerir¶

• "Daha az kod, akılda tutulacak daha az şey demektir"
• "Daha az kod, daha az bakım demektir"
• Daha az kod, daha az hata demektir
• Kod bir yükümlülüktür, varlık değil -- en aza indirin

4. Temiz Kod Tüm Testleri Geçer¶

• Testlerin yüzde sıfırını geçen kod kirli koddur
• %95 temiz olan ancak testleri geçmeyen kod yeterince temiz değildir
• Testler, yeniden yapılandırma için bir güvenlik ağı görevi görür

Sonuç¶

"Temiz kodun bakımı daha kolay ve daha ucuzdur!"

• Bir yazılım projesinin yaşam döngüsünün büyük bölümü bakıma harcanır
• Temiz kod, süregelen geliştirme maliyetini azaltır
• Yeni ekip üyeleri daha hızlı adapte olabilir

Referans: RefactoringGuru -- Temiz Kod

Modül A: Teknik Borç -- Metafor¶

Teknik Borç Nedir?¶

Teknik borç, Ward Cunningham tarafından ortaya atılan bir metafordur. Hızlı ve özensiz kodlama kararlarını finansal borçla karşılaştırır:

• Borç almak: Hızlı, özensiz kod yazarak şimdi daha hızlı teslim edersiniz
• Faiz ödemeleri: Kirli kodla her çalışmanızda, onu anlamak ve değiştirmek için ekstra zaman harcarsınız
• İflas: Sonunda kod tabanı o kadar dağınık hale gelir ki ileri geliştirme neredeyse imkansız olur

"Yeni özellikler için test yazmadan geçici olarak hızlanabilirsiniz, ancak bu, sonunda borcu test yazarak ödeyene kadar ilerlemenizi her gün yavaşlatacaktır." -- RefactoringGuru

Borç Sarmalı¶

Hızlı ve Özensiz Kod  -->  Teknik Borç Birikir
       |                         |
       v                         v
  Şimdi Daha Hızlı Teslim  Geliştirme Yavaşlar
       |                         |
       v                         v
  Daha Fazla Kısayol       Daha Fazla Hata, Daha Fazla Karmaşıklık
       |                         |
       v                         v
  Daha da Fazla Borç   -->  Proje Bakılamaz Hale Gelebilir

Referans: RefactoringGuru -- Teknik Borç

Teknik Borç Döngüsü (Diyagram)¶

Modül A: Teknik Borç Nedenleri¶

Temel Bakış Açısı¶

• Herkes zaman zaman teknik borç biriktirir
• Önemli olan kontrolden çıkmasına izin vermemektir
• Yeniden yapılandırma, teknik borcu ödemenin birincil yöntemidir

Modül A: Ne Zaman Yeniden Yapılandırılır -- Üçler Kuralı¶

Üçler Kuralı, ne zaman yeniden yapılandırma yapılacağına karar vermek için basit bir sezgisel yöntemdir:

1. İlk Sefer -- Sadece Yapın¶

• Bir şeyi ilk kez yapıyorsanız, sadece tamamlayın
• Kod mükemmel olmasa bile ilerleyin

2. İkinci Sefer -- Tekrarlamaya İçerlenin¶

• Benzer bir şeyi ikinci kez yaptığınızda, kendinizi tekrarlamak zorunda kalmanıza içerlenin
• Ama yine de yapın (şimdilik)

3. Üçüncü Sefer -- Yeniden Yapılandırın¶

• Bir şeyi üçüncü kez yapıyorsanız, yeniden yapılandırma zamanıdır
• Üç deneme ve yeniden yapılandırırsınız!

"Bir şeyi ilk kez yaptığınızda, sadece yapın. İkinci kez tekrarlamaya içerlenirsiniz ama yine de yaparsınız. Üçüncü kez yeniden yapılandırırsınız." -- RefactoringGuru

Referans: RefactoringGuru -- Ne Zaman Yeniden Yapılandırılır

Modül A: Ne Zaman Yeniden Yapılandırılır -- Belirli Durumlar¶

Özellik Eklerken¶

Yeniden yapılandırma, özellik eklerken iki şekilde yardımcı olur:

1. Başkalarının Kodunu Anlama -- Kodu daha açık hale getirmek için yeniden yapılandırma, neler olduğunu anlamanıza yardımcı olur. "Temiz kodda değişiklik yapmak çok daha kolaydır."
2. Eklemeyi Kolaylaştırma -- Bazen mevcut kod yapısı yeni bir özellik eklemeyi çok zorlaştırır. Önce yeniden yapılandırma yapmak yeni özelliği çok daha kolay uygulanabilir hale getirebilir.

Hata Düzeltirken¶

• "Koddaki hatalar tıpkı gerçek hayattakiler gibi davranır: kodun en karanlık, en kirli yerlerinde yaşarlar."
• Sorunlu kodu önce temizleyerek, hatalar daha kolay tanımlanır ve çözülür
• Yöneticiler hataların düzeltilmesi gerektiğini anlar, bu nedenle yeniden yapılandırmayı hata düzeltmeleriyle birleştirebilirsiniz

Kod İncelemesi Sırasında¶

• Kod incelemesi, kod kamuya açık hale gelmeden önce düzenlemenin son şansıdır
• İkili çalışmada en iyi sonuç verir: inceleyici değişiklikler önerir ve yazar bunları hemen uygular
• Basit yeniden yapılandırmalarla başlayın, karmaşık olanları takip görevleri olarak ele alın

Modül A: Nasıl Yeniden Yapılandırılır -- Temel İlke¶

"Yeniden yapılandırma, her biri mevcut kodu biraz daha iyi hale getirirken programı çalışır durumda bırakan bir dizi küçük değişiklik olarak yapılmalıdır." -- RefactoringGuru

Çalışan Kod --> Küçük Değişiklik --> Hala Çalışan Kod
     |                                   |
     v                                   v
  Test Geçer                          Test Geçer
     |                                   |
     v                                   v
Küçük Değişiklik --> Hala Çalışan Kod --> Küçük Değişiklik ...

• Her bireysel yeniden yapılandırma o kadar küçüktür ki yanlış gitme olasılığı çok düşüktür
• Sistem her küçük adımdan sonra tam işlevsel kalır
• Bir şey bozulursa, tam olarak hangi küçük değişikliğin neden olduğunu bilirsiniz

Referans: RefactoringGuru -- Nasıl Yeniden Yapılandırılır

Modül A: Yeniden Yapılandırma Kontrol Listesi¶

Yeniden yapılandırma öncesinde, sırasında ve sonrasında şu üç koşulu doğrulayın:

1. Kod Daha Temiz Olmalıdır¶

• Yeniden yapılandırma sonrasında kod hala aynı derecede kirli ise, zaman kaybediyorsunuz
• Bazen bu, birden fazla yeniden yapılandırmayı tek bir büyük değişiklikte birleştirdiğinizde olur
• Ciddi sorunlu kodlar için tam yeniden yazma düşünün -- ancak yalnızca testleri yazdıktan ve yeterli zaman ayırdıktan sonra

2. Yeniden Yapılandırma Sırasında Yeni İşlevsellik Oluşturulmamalıdır¶

• "Yeniden yapılandırmayı ve yeni özelliklerin doğrudan geliştirilmesini karıştırmayın"
• Yeniden yapılandırma ve yeni özellikleri netlik ve izlenebilirlik için ayrı commit'ler olarak tutun

3. Tüm Mevcut Testler Geçmelidir¶

• Yeniden yapılandırma sonrasında tüm mevcut testler hala geçmelidir
• Senaryo 1: Yeniden yapılandırma sırasında bir hata yaptınız -- küçük hatayı düzeltin
• Senaryo 2: Testler çok düşük seviyeydi (davranış yerine özel metotları test ediyordu) -- testleri yeniden yapılandırın veya daha yüksek seviye BDD tarzı testler yazın

Modül A: Güvenli Yeniden Yapılandırma İş Akışı¶

Adım Adım Süreç¶

1. Yeniden yapılandırmak istediğiniz kod için kapsamlı bir test paketine sahip olduğunuzdan emin olun
2. Her seferinde bir küçük değişiklik yapın
3. Her değişiklikten sonra tüm testleri çalıştırın
4. Testler geçerse, bir sonraki değişikliğe geçin
5. Testler başarısız olursa, değişikliği hemen geri alın ve farklı bir yaklaşım deneyin
6. Sık sık commit yapın böylece bir şeyler ters giderse kolayca geri dönebilirsiniz
7. Nihai sonucu gözden geçirin -- kod daha temiz mi?

Yardımcı Araçlar¶

Yeniden Yapılandırma İş Akışı (Diyagram)¶

Modül A: Özet¶

Temel Noktalar -- Yeniden Yapılandırma Nedir?¶

• Yeniden yapılandırma = dış davranışı değiştirmeden kod yapısını iyileştirme
• Temiz kod açık, tekrardan arınmış, minimum, test edilmiş ve bakımı kolaydır
• Kirli kod, gelecek geliştirmeyi yavaşlatan teknik borç oluşturur
• Teknik borç; iş baskısı, test eksikliği, kötü dokümantasyon, sıkı bağlı bileşenler ve daha fazlasından kaynaklanır
• Üçler Kuralını kullanın: ilk seferde yapın, ikinci seferde içerlenin, üçüncü seferde yeniden yapılandırın
• Özellik eklerken, hata düzeltirken ve kod incelemeleri sırasında yeniden yapılandırın
• Küçük, artımlı değişiklikler yapın ve tüm testlerin geçmesini sağlayın
• Yeniden yapılandırma ve özellik geliştirmeyi asla aynı commit'te karıştırmayın

"Herhangi bir aptal bilgisayarın anlayabileceği kod yazabilir. İyi programcılar insanların anlayabileceği kod yazar." -- Martin Fowler

Modül B: Şişkinler (Bloaters)¶

O Kadar Büyümüş Kod, Metotlar ve Sınıflar ki Çalışmak Zorlaşmıştır¶

Modül B: Şişkinler (Bloaters) -- Genel Bakış¶

Şişkinler (Bloaters), o kadar devasa boyutlara ulaşmış kod, metotlar ve sınıflardır ki bunlarla çalışmak zorlaşır. Genellikle bu kokular hemen ortaya çıkmaz; daha çok program geliştikçe zamanla birikir (ve özellikle kimse onları ortadan kaldırma çabası göstermediğinde).

5 Şişkin Kokusu¶

Referans: RefactoringGuru -- Şişkinler

Modül B: Şişkin #1 -- Uzun Metot (Long Method)¶

Nedir?¶

Bir metot çok fazla satır kod içerir. Genel olarak, on satırdan uzun herhangi bir metot sizi soru sormaya başlatmalıdır.

Belirtiler ve Semptomlar¶

• Metot 10-20 satırın ötesine büyümüştür
• Metodun farklı bölümlerinin ne yaptığını açıklamak için yorumlara ihtiyaç duyarsınız
• Metot adı, metodun yaptığı her şeyi tam olarak tanımlamaz
• Derinlemesine iç içe kontrol yapıları vardır

Sorunun Nedenleri¶

• Mevcut bir metoda ekleme yapmak, yeni bir metot oluşturmaktan zihinsel olarak daha kolaydır
• "Bu iki satırı buraya ekleyeyim..." -- ve büyümeye devam eder
• Bir metot oluşturmak, mevcut bir metoda ekleme yapmaktan daha zor olduğundan, çoğu kod mevcut metotlara ekleme olarak yazılır
• Metot başlangıçta küçük başlamış ancak zamanla büyümüştür

Referans: RefactoringGuru -- Uzun Metot

Uzun Metot - Önce (Kod Kokusu)¶

Uzun Metot - Sonra (Yeniden Yapılandırılmış)¶

Modül B: Şişkin #1 -- Uzun Metot (Long Method) (Java Örneği -- Önce)¶

// KOKU: Uzun Metot -- bu metot çok fazla iş yapıyor
public void processOrder(Order order) {
    // Siparişi doğrula (10+ satır)
    if (order == null) throw new IllegalArgumentException("Order is null");
    if (order.getItems().isEmpty())
        throw new IllegalStateException("Order has no items");
    for (Item item : order.getItems()) {
        if (item.getQuantity() <= 0)
            throw new IllegalStateException("Invalid quantity");
        if (!inventory.isAvailable(item.getProductId(), item.getQuantity()))
            throw new IllegalStateException("Product not available");
    }

    // Fiyatları hesapla (10+ satır)
    double subtotal = 0;
    for (Item item : order.getItems()) {
        subtotal += item.getPrice() * item.getQuantity();
    }
    double tax = subtotal * 0.08;
    double shipping = subtotal > 100 ? 0 : 9.99;

    // İndirimleri uygula (10+ satır)
    if (order.getCustomer().isLoyalMember()) {
        subtotal *= 0.90;
    }
    double total = subtotal + tax + shipping;

    // Envanteri güncelle, siparişi kaydet, e-posta gönder... (20+ satır daha)
}

Modül B: Şişkin #1 -- Uzun Metot (Long Method) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Metot Çıkarma uygulandı
public void processOrder(Order order) {
    validateOrder(order);
    double subtotal = calculateSubtotal(order);
    double tax = calculateTax(subtotal);
    double shipping = calculateShipping(subtotal);
    subtotal = applyDiscounts(order, subtotal);
    double total = subtotal + tax + shipping;
    updateInventory(order);
    saveOrder(order, total);
    sendConfirmationEmail(order, total);
}

private void validateOrder(Order order) {
    if (order == null) throw new IllegalArgumentException("Order is null");
    if (order.getItems().isEmpty())
        throw new IllegalStateException("Order has no items");
    for (Item item : order.getItems()) {
        validateItem(item);
    }
}

private double calculateSubtotal(Order order) {
    return order.getItems().stream()
        .mapToDouble(item -> item.getPrice() * item.getQuantity())
        .sum();
}

Modül B: Şişkin #1 -- Uzun Metot (Long Method) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Tüm nesne yönelimli kod türleri arasında, kısa metotlara sahip sınıflar en uzun ömürlüdür
• Bir metot ne kadar uzunsa, anlaması ve bakımı o kadar zordur
• Uzun metotlar istenmeyen tekrarlanan kod için mükemmel bir saklanma yeridir
• Artık temiz kodunuz olduğunda, gerçekten etkili performans optimizasyonları bulma olasılığınız daha yüksektir

Modül B: Şişkin #2 -- Büyük Sınıf (Large Class)¶

Nedir?¶

Bir sınıf birçok alan, metot ve kod satırı içerir. Programlar büyüdükçe sınıflar zamanla şişer.

Belirtiler ve Semptomlar¶

• Sınıf çok fazla alana sahiptir (farklı kavramları temsil eden 5-10'dan fazla)
• Sınıf çok fazla metoda sahiptir (birden fazla sorumluluğu kapsar)
• Sınıfın ne yaptığını "ve" kullanmadan tek bir cümlede tanımlayamazsınız

Sorunun Nedenleri¶

• Sınıflar genellikle küçük başlar ancak program büyüdükçe zamanla şişer
• Programcılar, yeni bir özelliği mevcut bir sınıfa yerleştirmeyi özellik için yeni bir sınıf oluşturmaktan zihinsel olarak daha az yorucu bulur
• "Bu sınıf zaten siparişleri yönetiyor... kargo mantığını da buraya ekleyeyim"

Referans: RefactoringGuru -- Büyük Sınıf

Büyük Sınıf - Önce (Kod Kokusu)¶

Büyük Sınıf - Sonra (Yeniden Yapılandırılmış)¶

Modül B: Şişkin #2 -- Büyük Sınıf (Large Class) (Java Örneği -- Önce)¶

// KOKU: Büyük Sınıf -- Order çok fazla sorumluluk üstleniyor
public class Order {
    // Müşteri alanları
    private String customerName, customerEmail, customerPhone;
    // Kargo adresi alanları
    private String shippingStreet, shippingCity, shippingState, shippingZip;
    // Fatura adresi alanları
    private String billingStreet, billingCity, billingState, billingZip;
    // Sipariş alanları
    private List<Item> items;
    private double subtotal, tax, shipping, discount, total;
    private Date orderDate, shipDate, deliveryDate;
    private String status, trackingNumber, paymentMethod;

    // Sipariş, kargo, faturalama, bildirimler, raporlama metotları...
    // Birden fazla sorumluluğu kapsayan 50+ metot
    public void addItem(Item item) { /* ... */ }
    public void calculateTotal() { /* ... */ }
    public void shipOrder() { /* ... */ }
    public void sendConfirmation() { /* ... */ }
    public void generateInvoice() { /* ... */ }
    public void updateCustomerProfile() { /* ... */ }
}

Modül B: Şişkin #2 -- Büyük Sınıf (Large Class) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Sınıf Çıkarma -- her sınıfın tek bir sorumluluğu var
public class Order {
    private Customer customer;
    private ShippingAddress shippingAddress;
    private BillingAddress billingAddress;
    private List<Item> items;
    private OrderStatus status;

    public void addItem(Item item) { /* ... */ }
    public double calculateTotal() { /* ... */ }
}

public class Customer {
    private String name, email, phone;
    public void updateProfile() { /* ... */ }
}

public class ShippingAddress {
    private String street, city, state, zip;
}

public class BillingAddress {
    private String street, city, state, zip;
}

public class OrderShipper {
    public void shipOrder(Order order) { /* ... */ }
    public void sendConfirmation(Order order) { /* ... */ }
}

Modül B: Şişkin #2 -- Büyük Sınıf (Large Class) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Geliştiriciler bir sınıf için çok sayıda özelliği hatırlamak zorunda kalmaz
• Büyük sınıfları bölmek sıklıkla kod tekrarını ve gereksiz işlevselliği ortadan kaldırır
• Her sınıfın tek bir net amacı vardır (Tek Sorumluluk İlkesi)
• Daha küçük sınıflar izole olarak test etmek daha kolaydır
• Daha küçük, odaklı sınıflar diğer bağlamlarda yeniden kullanılabilir

Modül B: Şişkin #3 -- İlkel Takıntı (Primitive Obsession)¶

Nedir?¶

Alan kavramları için küçük nesneler oluşturmak yerine ilkel türlerin (int, String, double, boolean) aşırı kullanımıdır.

Belirtiler ve Semptomlar¶

• Basit görevler için küçük nesneler yerine ilkellerin kullanımı (para birimi, aralıklar, telefon numaraları için özel dizeler vb.)
• Bilgi kodlama için sabit değerlerin kullanımı (USER_ADMIN_ROLE = 1 gibi)
• Veri dizilerinde kullanım için alan adları olarak dize sabitlerinin kullanımı

Sorunun Nedenleri¶

• İlkeller "sadece bir değer saklamak için" oluşturulur ve sonunda kullanımları artar
• Bir alan oluşturmak, tamamen yeni bir sınıf oluşturmaktan daha kolaydır
• "Telefon numarası için sadece bir String kullanayım..."
• İlkeller genellikle tembellikten doğar: bir int veya String kullanmak yeni bir sınıf oluşturmaktan daha basit görünür

Referans: RefactoringGuru -- İlkel Takıntı

Modül B: Şişkin #3 -- İlkel Takıntı (Primitive Obsession) (Java Örneği -- Önce)¶

// KOKU: İlkel Takıntı -- her yerde ilkeller
public class Employee {
    private String name;
    private String phoneNumber;        // PhoneNumber nesnesi olmalı
    private int currencyAmount;        // Kuruş mu? Dolar mı? Euro mu?
    private String zipCode;            // Format doğrulaması yapmalı
    private int temperatureInFahrenheit;
    private String startDate;          // Tarih için String mi? Gerçekten mi?
    private int employeeType;          // 1=Mühendis, 2=Satışçı, 3=Yönetici
    private String socialSecurityNumber; // Doğrulama yok!

    // Koşullarda kullanılan tür kodu
    public double calculatePay() {
        if (employeeType == 1) {
            return baseSalary;
        } else if (employeeType == 2) {
            return baseSalary + commission;
        } else if (employeeType == 3) {
            return baseSalary + bonus;
        }
        return 0;
    }
}

Modül B: Şişkin #3 -- İlkel Takıntı (Primitive Obsession) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Veri Değerini Nesneyle Değiştirme, Tür Kodunu Alt Sınıflarla Değiştirme
public class PhoneNumber {
    private String areaCode;
    private String number;
    public PhoneNumber(String areaCode, String number) {
        validate(areaCode, number);
        this.areaCode = areaCode;
        this.number = number;
    }
    private void validate(String areaCode, String number) { /* ... */ }
    public String format() { return "(" + areaCode + ") " + number; }
}

public class Money {
    private long amountInCents;
    private Currency currency;
    public Money(long amountInCents, Currency currency) {
        this.amountInCents = amountInCents;
        this.currency = currency;
    }
    public Money add(Money other) { /* para birimi güvenli toplama */ }
}

// Tür kodu çok biçimlilikle değiştirildi
abstract class Employee {
    abstract double calculatePay();
}
class Engineer extends Employee {
    double calculatePay() { return getBaseSalary(); }
}

Modül B: Şişkin #3 -- İlkel Takıntı (Primitive Obsession) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• İlkeller yerine nesnelerin kullanımı sayesinde kod daha esnek hale gelir
• Kodun daha iyi anlaşılabilirliği ve organizasyonu
• Aynı veriyi işleyen tekrarlanan kodu bulmak daha kolaydır
• Değer nesnesi içinde doğrulama yapılabilir (örn. telefon numarası formatı)

Modül B: Şişkin #4 -- Uzun Parametre Listesi (Long Parameter List)¶

Nedir?¶

Bir metot üçten veya dörtten fazla parametreye sahiptir, bu da onu anlamayı ve doğru kullanmayı zorlaştırır.

Belirtiler ve Semptomlar¶

• Tek satıra sığmayacak kadar uzun metot imzaları
• Birbirinden ayırt edilmesi zor parametreler
• Çağıranlar sıklıkla yanlış argümanları yanlış pozisyonlara geçirir

Sorunun Nedenleri¶

• Uzun bir parametre listesi, birkaç tür algoritmanın tek bir metotta birleştirilmesinden sonra ortaya çıkabilir
• Uzun bir liste, hangi algoritmanın çalıştırılacağını ve nasıl çalıştırılacağını kontrol etmek için oluşturulmuş olabilir
• Uzun parametre listeleri, sınıfları birbirinden daha bağımsız hale getirme çabalarından da kaynaklanabilir (bir nesne geçirmek yerine tek tek değerler geçirilir)
• Uzun listeler "uzadıkça çelişkili ve kullanımı zor" hale gelir

Referans: RefactoringGuru -- Uzun Parametre Listesi

Modül B: Şişkin #4 -- Uzun Parametre Listesi (Long Parameter List) (Java Örneği -- Önce)¶

// KOKU: Uzun Parametre Listesi -- 13 parametre!
public void createUser(String firstName, String lastName,
    String email, String phone, String street,
    String city, String state, String zipCode,
    String country, int age, String gender,
    boolean isActive, String role) {
    // ...
}

// Başka bir örnek -- hesaplanabilecek parametre değerleri
public double calculateFinalPrice(
    int quantity, double itemPrice,
    double seasonalDiscount, double memberDiscount,
    double taxRate, double shippingCost,
    boolean applyPromo) {
    double base = quantity * itemPrice;
    double discount = base * (seasonalDiscount + memberDiscount);
    double tax = (base - discount) * taxRate;
    return base - discount + tax + shippingCost;
}

Modül B: Şişkin #4 -- Uzun Parametre Listesi (Long Parameter List) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Parametre Nesnesi Tanıtma + Parametreyi Metot Çağrısıyla Değiştirme
public class UserInfo {
    private String firstName, lastName, email, phone;
    private int age;
    private String gender;
    private boolean isActive;
    private String role;
    // yapıcı, getter'lar...
}

public class Address {
    private String street, city, state, zipCode, country;
    // yapıcı, getter'lar...
}

public void createUser(UserInfo userInfo, Address address) {
    // Temiz, açık ve anlaması kolay
}

// Parametreyi Metot Çağrısıyla Değiştirme
public double calculateFinalPrice(int quantity, double itemPrice) {
    double base = quantity * itemPrice;
    double discount = base * getSeasonalDiscount() + getMemberDiscount();
    double tax = (base - discount) * getTaxRate();
    return base - discount + tax + getShippingCost();
    // Metot ihtiyaç duyduğu değerleri dahili olarak elde eder
}

Modül B: Şişkin #4 -- Uzun Parametre Listesi (Long Parameter List) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Daha okunabilir, daha kısa kod
• Yeniden yapılandırma, daha önce fark edilmeyen tekrarlanan kodu ortaya çıkarabilir
• Metot imzaları kendi kendini belgeleme haline gelir

Ne Zaman Görmezden Gelinir¶

• Parametre sayısını azaltmak için sınıflar arasında istenmeyen bağımlılıklar oluşturmayın
• Parametreler arasındaki tek bağlantı bu metotta birlikte görünmeleri ise, parametre nesnesi tanıtmak erken olabilir

Modül B: Şişkin #5 -- Veri Kümeleri (Data Clumps)¶

Nedir?¶

Aynı değişken grupları kodun farklı bölümlerinde tekrar tekrar görünür. Bu kümeler kendi sınıflarına dönüştürülmelidir.

Belirtiler ve Semptomlar¶

• Aynı alan grubu birden fazla sınıfta görünür (örn. cadde, şehir, postaKodu)
• Aynı parametre grubu birden fazla metot imzasında görünür
• Gruptan bir değeri kaldırmak geri kalanını anlamsız kılar

Sorunun Nedenleri¶

• Veri kümeleri genellikle kopyala-yapıştır programlama yapıldığında ortaya çıkar
• Veri grupları birlikte dolaştırılır ancak asla bir kavram olarak resmileştirilmez
• İyi bir test: veri değerlerinden birini silin -- geri kalanlar hala anlamlı mı? Değilse, bu bir kümedir

Referans: RefactoringGuru -- Veri Kümeleri

Modül B: Şişkin #5 -- Veri Kümeleri (Data Clumps) (Java Örneği -- Önce)¶

// KOKU: Veri Kümeleri -- aynı üç alan her yerde tekrarlanıyor
class Customer {
    private String street;
    private String city;
    private String zipCode;
    // diğer alanlar...
}

class Order {
    private String shippingStreet;
    private String shippingCity;
    private String shippingZipCode;
    // diğer alanlar...
}

class Warehouse {
    private String street;
    private String city;
    private String zipCode;
    // diğer alanlar...
}

// Metot imzalarında aynı veri kümesi
void deliverOrder(String street, String city, String zipCode,
                  String recipientName) {
    // ...
}

Modül B: Şişkin #5 -- Veri Kümeleri (Data Clumps) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Sınıf Çıkarma -- Address veri kümesini kapsüller
public class Address {
    private String street;
    private String city;
    private String zipCode;

    public Address(String street, String city, String zipCode) {
        this.street = street;
        this.city = city;
        this.zipCode = zipCode;
    }

    public String format() {
        return street + ", " + city + " " + zipCode;
    }
    // getter'lar, equals, hashCode...
}

class Customer { private Address address; }
class Order { private Address shippingAddress; }
class Warehouse { private Address address; }

// Parametre Nesnesi Tanıtma ile temiz metot imzası
void deliverOrder(Address deliveryAddress, String recipientName) {
    // ...
}

Modül B: Şişkin #5 -- Veri Kümeleri (Data Clumps) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Kodun anlaşılmasını ve organizasyonunu iyileştirir
• Tekrarlanan alan gruplarını ortadan kaldırarak kod boyutunu azaltır
• Veriyle ilişkili işlemler yeni sınıfa taşınabilir (örn. adres biçimlendirme, doğrulama)

Ne Zaman Görmezden Gelinir¶

• Tam nesneleri parametre olarak geçirmek sınıflar arasında istenmeyen bağımlılıklar oluşturabilir
• Veri grubu yalnızca iki yerde birlikte görünüyorsa, yeni bir sınıfın ek yükü buna değmeyebilir

Modül B: Özet¶

Temel Noktalar -- Şişkinler (Bloaters)¶

Ortak Konu¶

Tüm şişkinler zamanla kademeli olarak büyür. Kimse ilk gün kasıtlı olarak 200 satırlık bir metot yazmaz. Dikkat ve düzenli yeniden yapılandırma, şişkinlerin tutunmasını önler.

"Bir metot içinde bir şeyi yorumlama ihtiyacı hissediyorsanız, o kodu alıp yeni bir metoda koymalısınız. Tek bir satır bile, açıklama gerektiriyorsa ayrı bir metoda çıkarılabilir ve çıkarılmalıdır." -- Martin Fowler

Modül C: Nesne Yönelim Kötüye Kullananlar (OO Abusers)¶

Nesne Yönelimli Programlama İlkelerinin Eksik veya Yanlış Uygulanması¶

Modül C: Nesne Yönelim Kötüye Kullananlar (OO Abusers) -- Genel Bakış¶

Nesne Yönelim Kötüye Kullananlar (OO Abusers), nesne yönelimli programlama ilkelerinin eksik veya yanlış uygulandığı durumlardır.

4 NE Kötüye Kullanan Kokusu¶

Tüm bu kokular, NYP ilkelerinin eksik veya yanlış uygulamalarını temsil eder.

Referans: RefactoringGuru -- NE Kötüye Kullananlar

Modül C: NE Kötüye Kullanan #1 -- Switch İfadeleri (Switch Statements)¶

Nedir?¶

Bir tür veya koşula dayalı olarak farklı eylemler gerçekleştiren karmaşık bir switch operatörünüz veya if ifadeleri diziniz vardır.

Belirtiler ve Semptomlar¶

• Birden fazla yerde aynı koşulu test eden karmaşık bir switch veya if-else zinciri
• Aynı switch yapısının, türün işlendiği her yerde muhtemelen tekrarlanması
• Yeni bir tür eklemek her switch ifadesini değiştirmeyi gerektirir

Sorunun Nedenleri¶

• switch ve case'in nispeten nadir kullanımı, nesne yönelimli kodun ayırt edici özelliklerinden biridir
• Genellikle bir switch programın farklı yerlerinde dağılmıştır
• Yeni bir koşul eklendiğinde, tüm switch kodunu bulup değiştirmeniz gerekir
• Genel kural olarak, bir switch gördüğünüzde çok biçimliliği düşünmelisiniz

Referans: RefactoringGuru -- Switch İfadeleri

Switch İfadeleri - Önce (Kod Kokusu)¶

Switch İfadeleri - Sonra (Yeniden Yapılandırılmış)¶

Modül C: NE Kötüye Kullanan #1 -- Switch İfadeleri (Switch Statements) (Java Örneği -- Önce)¶

// KOKU: Switch İfadeleri -- tekrarlanan koşullu mantık
public class PayrollCalculator {

    public double calculatePay(Employee employee) {
        switch (employee.getType()) {
            case ENGINEER:
                return employee.getMonthlySalary();
            case SALESMAN:
                return employee.getMonthlySalary()
                       + employee.getCommission();
            case MANAGER:
                return employee.getMonthlySalary()
                       + employee.getBonus();
            default:
                throw new RuntimeException("Invalid employee type");
        }
    }

    // Aynı switch başka bir metotta tekrarlanıyor!
    public int calculateVacationDays(Employee employee) {
        switch (employee.getType()) {
            case ENGINEER:  return 15;
            case SALESMAN:  return 12;
            case MANAGER:   return 20;
            default: throw new RuntimeException("Invalid type");
        }
    }
}

Modül C: NE Kötüye Kullanan #1 -- Switch İfadeleri (Switch Statements) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Koşullu İfadeyi Çok Biçimlilikle Değiştirme
public abstract class Employee {
    private double monthlySalary;

    public abstract double calculatePay();
    public abstract int getVacationDays();

    public double getMonthlySalary() { return monthlySalary; }
}

public class Engineer extends Employee {
    public double calculatePay() { return getMonthlySalary(); }
    public int getVacationDays() { return 15; }
}

public class Salesman extends Employee {
    private double commission;
    public double calculatePay() {
        return getMonthlySalary() + commission;
    }
    public int getVacationDays() { return 12; }
}

public class Manager extends Employee {
    private double bonus;
    public double calculatePay() {
        return getMonthlySalary() + bonus;
    }
    public int getVacationDays() { return 20; }
}

Modül C: NE Kötüye Kullanan #1 -- Switch İfadeleri (Switch Statements) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Çok biçimlilik yoluyla iyileştirilmiş kod organizasyonu
• Yeni türler eklemek daha kolay -- sadece yeni bir alt sınıf ekleyin (Açık/Kapalı İlkesi)
• Kod tabanı boyunca dağılmış tekrarlanan koşullu mantığı ortadan kaldırır

Ne Zaman Görmezden Gelinir¶

• Bir switch basit eylemler gerçekleştirdiğinde ve yalnızca tek bir yerde göründüğünde
• Basit fabrika metotları (Factory Method veya Abstract Factory kalıpları) genellikle kabul edilebilir
• Switch'in değişme olasılığı düşükse, çok biçimlilik aşırıya kaçabilir

Modül C: NE Kötüye Kullanan #2 -- Geçici Alan (Temporary Field)¶

Nedir?¶

Geçici alanlar, değerlerini (ve dolayısıyla nesneler tarafından ihtiyaç duyulmaları) yalnızca belirli koşullar altında alır. Bu koşulların dışında boştur veya alakasız veri içerir.

Belirtiler ve Semptomlar¶

• Yalnızca belirli algoritma yürütmesi sırasında doldurulan ve kullanılan nesne alanları
• Zamanın çoğunda null veya boş olan alanlar
• Neredeyse her zaman boş olan alanlarda veri görmeyi beklersiniz

Sorunun Nedenleri¶

• Genellikle geçici alanlar, büyük miktarda girdi gerektiren bir algoritmada kullanılmak üzere oluşturulur
• Programcı, metotta birçok parametre oluşturmak yerine bu veriler için sınıfta alanlar oluşturmaya karar verir
• Bu alanlar yalnızca algoritmada kullanılır ve geri kalan zamanda işe yaramazdır
• Bu kod anlaşılması zordur çünkü nesne alanlarının tutarlı bir şekilde anlamlı veri içermesini beklersiniz

Referans: RefactoringGuru -- Geçici Alan

Modül C: NE Kötüye Kullanan #2 -- Geçici Alan (Temporary Field) (Java Örneği -- Önce)¶

// KOKU: Geçici Alan -- alanlar yalnızca ödeme sırasında anlamlı
public class Order {
    private List<Item> items;
    private Customer customer;

    // Bu alanlar yalnızca ödeme sırasında kullanılıyor!
    private double taxRate;          // Yalnızca ödeme sırasında ayarlanır
    private String promoCode;        // Yalnızca indirim uygulanırken ayarlanır
    private double shippingWeight;   // Yalnızca fiziksel ürünler için geçerli
    private String shippingMethod;   // Kargo seçilene kadar boş

    public double checkout() {
        // taxRate, promoCode, shippingWeight, shippingMethod kullanılır
        // Sipariş ödeme aşamasında değilken bunlar kafa karıştırıcıdır
        double subtotal = calculateSubtotal();
        double discount = promoCode != null ? applyPromo(promoCode) : 0;
        double tax = subtotal * taxRate;
        double shipping = calculateShipping(shippingWeight, shippingMethod);
        return subtotal - discount + tax + shipping;
    }
}

Modül C: NE Kötüye Kullanan #2 -- Geçici Alan (Temporary Field) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Sınıf Çıkarma -- ayrı ödeme bağlamı
public class Order {
    private List<Item> items;
    private Customer customer;

    public double calculateSubtotal() {
        return items.stream()
            .mapToDouble(item -> item.getPrice() * item.getQuantity())
            .sum();
    }
}

public class CheckoutContext {
    private double taxRate;
    private String promoCode;
    private double shippingWeight;
    private String shippingMethod;

    public CheckoutContext(double taxRate, String promoCode,
                           double shippingWeight, String shippingMethod) {
        this.taxRate = taxRate;
        this.promoCode = promoCode;
        this.shippingWeight = shippingWeight;
        this.shippingMethod = shippingMethod;
    }

    public double calculateFinalPrice(Order order) {
        double subtotal = order.calculateSubtotal();
        double discount = promoCode != null ? applyPromo(promoCode, subtotal) : 0;
        double tax = subtotal * taxRate;
        double shipping = calculateShipping(shippingWeight, shippingMethod);
        return subtotal - discount + tax + shipping;
    }
}

Modül C: NE Kötüye Kullanan #2 -- Geçici Alan (Temporary Field) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Daha iyi kod açıklığı ve organizasyonu -- alanların ne zaman anlamlı değerlere sahip olduğu konusunda artık kafa karışıklığı yok
• Bir sınıftaki tüm alanlar her zaman anlamlıdır
• Kod hakkında mantık yürütmek daha kolay hale gelir

Ne Zaman Görmezden Gelinir¶

• Geçici durum gerçekten geçiciyse ve açıkça belgelenmişse
• Algoritma yeterince basitse ve geçici alanlar kafa karışıklığına neden olmuyorsa

Modül C: NE Kötüye Kullanan #3 -- Reddedilen Miras (Refused Bequest)¶

Nedir?¶

Bir alt sınıf, üst sınıflarından miras alınan metot ve özelliklerin yalnızca bir kısmını kullanıyorsa, hiyerarşi dengesizdir. İhtiyaç duyulmayan metotlar ya kullanılmadan kalabilir ya da istisna fırlatmak üzere yeniden tanımlanabilir.

Belirtiler ve Semptomlar¶

• Bir alt sınıf, üst metotları UnsupportedOperationException fırlatmak için geçersiz kılar
• Bir alt sınıf, miras alınan metotların çoğunu kullanılmadan bırakır
• Kalıtım ilişkisi gerçek bir "bir-tür" ilişkisini modellemez

Sorunun Nedenleri¶

• Birisi, sınıflar arasında kalıtım oluşturmaya yalnızca bir üst sınıftaki kodu yeniden kullanma arzusuyla motive olmuştur
• Ancak üst sınıf ve alt sınıf doğaları gereği tamamen farklıdır
• İkisinin de dört bacağı olduğu için Köpeği Sandalyeden türetmeye benzer

Referans: RefactoringGuru -- Reddedilen Miras

Modül C: NE Kötüye Kullanan #3 -- Reddedilen Miras (Refused Bequest) (Java Örneği -- Önce)¶

// KOKU: Reddedilen Miras -- Dog kullanamayacağı fly() metodunu miras alıyor
public class Animal {
    public void walk() { /* yürüme mantığı */ }
    public void fly()  { /* uçma mantığı */ }
    public void swim() { /* yüzme mantığı */ }
    public void eat()  { /* yeme mantığı */ }
}

public class Dog extends Animal {
    // Dog yürüyebilir, yüzebilir ve yiyebilir -- ama UÇAMAZ
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Dogs can't fly!");
    }
}

public class Fish extends Animal {
    // Fish yüzebilir ve yiyebilir -- ama YÜRÜYEMEZ veya UÇAMAZ
    @Override
    public void walk() {
        throw new UnsupportedOperationException("Fish can't walk!");
    }
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Fish can't fly!");
    }
}

Modül C: NE Kötüye Kullanan #3 -- Reddedilen Miras (Refused Bequest) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Üst Sınıf Çıkarma + Kalıtımı Devretmeyle Değiştirme
public abstract class Animal {
    public abstract void eat();
}

public interface Walkable { void walk(); }
public interface Swimmable { void swim(); }
public interface Flyable { void fly(); }

public class Dog extends Animal implements Walkable, Swimmable {
    public void eat()  { /* yeme mantığı */ }
    public void walk() { /* yürüme mantığı */ }
    public void swim() { /* yüzme mantığı */ }
    // fly() metodu yok -- köpekler uçmaz!
}

public class Eagle extends Animal implements Walkable, Flyable {
    public void eat()  { /* yeme mantığı */ }
    public void walk() { /* yürüme mantığı */ }
    public void fly()  { /* uçma mantığı */ }
}

public class Fish extends Animal implements Swimmable {
    public void eat()  { /* yeme mantığı */ }
    public void swim() { /* yüzme mantığı */ }
}

Modül C: NE Kötüye Kullanan #3 -- Reddedilen Miras (Refused Bequest) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Kod açıklığını ve organizasyonunu iyileştirir
• Kafa karıştırıcı veya anlamsız kalıtım hiyerarşilerini ortadan kaldırır
• Liskov Yerine Geçme İlkesine uyar (bir alt tür, üst türünün yerine geçebilmelidir)
• UnsupportedOperationException fırlatan metotlar artık yok

Ne Zaman Görmezden Gelinir¶

• Reddedilen miras minimalse ve kafa karışıklığına neden olmuyorsa
• Kalıtım yoluyla yeniden kullanım önemli faydalar sağlıyorsa ve reddedilen metotlar açıkça belgelenmişse

Modül C: NE Kötüye Kullanan #4 -- Farklı Arayüzlere Sahip Alternatif Sınıflar (Alternative Classes with Different Interfaces)¶

Nedir?¶

İki sınıf aynı işlevleri yerine getirir ancak farklı metot adlarına sahiptir. Ortak bir arayüzü paylaşmalıdırlar.

Belirtiler ve Semptomlar¶

• Aynı şeyi yapan ancak farklı metot adlarına sahip iki sınıf
• İstemci kodu, iki sınıf arasında seçim yapmak için if-else kullanır
• Sınıflar birbirlerinin yerine kullanılamaz

Sorunun Nedenleri¶

• Bir sınıfı oluşturan geliştirici muhtemelen işlevsel olarak eşdeğer bir sınıfın zaten mevcut olduğunu bilmiyordu
• Ya da bağımsız olarak oluşturmuş ve arayüzleri birleştirmeyi düşünmemiştir

Referans: RefactoringGuru -- Farklı Arayüzlere Sahip Alternatif Sınıflar

Modül C: NE Kötüye Kullanan #4 -- Alternatif Sınıflar (Java Örneği -- Önce)¶

// KOKU: Farklı Arayüzlere Sahip Alternatif Sınıflar
public class EmailNotifier {
    public void sendEmail(String to, String subject, String body) {
        // e-posta bildirimi gönderir
    }
}

public class SMSNotifier {
    public void dispatchSMS(String phoneNumber, String message) {
        // SMS bildirimi gönderir
    }
}

// İstemci kodu her birinin belirli arayüzünü bilmek zorunda
public class NotificationService {
    public void notifyUser(User user, String message) {
        if (user.prefersEmail()) {
            EmailNotifier emailer = new EmailNotifier();
            emailer.sendEmail(user.getEmail(), "Notification", message);
        } else {
            SMSNotifier sms = new SMSNotifier();
            sms.dispatchSMS(user.getPhone(), message);
        }
    }
}

Modül C: NE Kötüye Kullanan #4 -- Alternatif Sınıflar (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Üst Sınıf Çıkarma / ortak arayüz
public interface Notifier {
    void send(String recipient, String message);
}

public class EmailNotifier implements Notifier {
    @Override
    public void send(String recipient, String message) {
        // 'recipient' (e-posta adresi) adresine e-posta bildirimi gönderir
    }
}

public class SMSNotifier implements Notifier {
    @Override
    public void send(String recipient, String message) {
        // 'recipient' (telefon numarası) numarasına SMS bildirimi gönderir
    }
}

// İstemci kodu ortak arayüzü kullanır -- çok biçimlilik!
public class NotificationService {
    public void notifyUser(User user, String message) {
        Notifier notifier = user.prefersEmail()
            ? new EmailNotifier()
            : new SMSNotifier();
        notifier.send(user.getContactInfo(), message);
    }
}

Modül C: NE Kötüye Kullanan #4 -- Alternatif Sınıflar (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Gereksiz tekrarlanan kodu ortadan kaldırır, kodu daha hafif hale getirir
• Birleşik bir arayüz aracılığıyla kod daha okunabilir ve anlaşılır hale gelir
• Çok biçimliliği etkinleştirir -- istemciler ortak arayüzü birbirinin yerine kullanabilir

Ne Zaman Görmezden Gelinir¶

• Bazen sınıfları birleştirmek, alternatif sınıflar her biri kendi sürümlemesine sahip farklı kütüphanelerde olduğunda imkansızdır

Modül C: Özet¶

Temel Noktalar -- Nesne Yönelim Kötüye Kullananlar (OO Abusers)¶

Ortak Konu¶

Tüm NE Kötüye Kullananlar, NYP ilkelerini yanlış anlama veya yanlış uygulamadan kaynaklanır. Çözüm neredeyse her zaman şudur: çok biçimliliği doğru kullanın, uygun olduğunda kalıtım yerine bileşimi tercih edin ve temiz arayüzler tasarlayın.

"Bir switch ifadesi gördüğünüzde, çok biçimliliği düşünün." -- RefactoringGuru

Modül D: Değişim Engelleyiciler (Change Preventers)¶

Kod Değiştirmeyi Orantısız Derecede Zorlaştıran Kokular¶

Modül D: Değişim Engelleyiciler (Change Preventers) -- Genel Bakış¶

Değişim Engelleyiciler (Change Preventers), kodunuzda bir yerde bir şeyi değiştirmeniz gerektiğinde, diğer birçok yerde de değişiklik yapmanız gerektiği anlamına gelen kokulardır. Sonuç olarak program geliştirme çok daha pahalı ve karmaşık hale gelir.

3 Değişim Engelleyici Kokusu¶

Bu kokular bazı açılardan zıttır: Iraksak Değişim bir sınıfın birçok değişiklikten muzdarip olmasıdır, Saçma Ameliyat ise bir değişikliğin birçok sınıfı etkilemesidir.

Referans: RefactoringGuru -- Değişim Engelleyiciler

Modül D: Değişim Engelleyici #1 -- Iraksak Değişim (Divergent Change)¶

Nedir?¶

Bir sınıfta değişiklik yaptığınızda kendinizi birbiriyle ilgisiz birçok metodu değiştirmek zorunda bulursunuz. Örneğin, yeni bir ürün türü eklerken ürünleri bulma, görüntüleme ve sipariş etme metotlarını değiştirmeniz gerekir.

Belirtiler ve Semptomlar¶

• Bir sınıf farklı, birbiriyle ilgisiz nedenlerle sık değişiklik gerektirir
• Bir sınıf farklı sınıflara ait olması gereken sorumlulukları biriktirmiştir
• Sınıf Tek Sorumluluk İlkesini ihlal eder

Sorunun Nedenleri¶

• Bu dağınık değişiklikler tipik olarak kötü program yapısından veya kopyala-yapıştır programlamadan kaynaklanır
• Bir sınıf zamanla kademeli olarak birden fazla sorumluluk üstlenmiştir
• "Bu Order sınıfı -- görüntüleme mantığını da buraya ekleyeyim"

Referans: RefactoringGuru -- Iraksak Değişim

Iraksak Değişim (Diyagram)¶

Modül D: Değişim Engelleyici #1 -- Iraksak Değişim (Divergent Change) (Java Örneği -- Önce)¶

// KOKU: Iraksak Değişim -- bir sınıf, birçok değişiklik nedeni
public class Order {
    private List<Item> items;
    private Customer customer;

    // Ürün türleri değiştiğinde değişir
    public void addProduct(Product p) { /* ... */ }

    // Görüntüleme formatı değiştiğinde değişir
    public String formatForDisplay() {
        return "Order: " + items.toString(); // HTML mi? JSON mu? XML mi?
    }

    // Veritabanı şeması değiştiğinde değişir
    public void saveToDatabase(Connection conn) {
        String sql = "INSERT INTO orders ...";
        // JDBC kodu burada
    }

    // Kargo kuralları değiştiğinde değişir
    public double calculateShipping() {
        if (getTotalWeight() > 50) return 15.99;
        return 5.99;
    }

    // Bildirim gereksinimleri değiştiğinde değişir
    public void sendConfirmation() {
        // e-posta gönderme mantığı
    }
}

Modül D: Değişim Engelleyici #1 -- Iraksak Değişim (Divergent Change) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Sınıf Çıkarma -- her sınıfın tek bir değişiklik nedeni var
public class Order {
    private List<Item> items;
    private Customer customer;
    public void addProduct(Product p) { /* ... */ }
    public List<Item> getItems() { return items; }
}

public class OrderFormatter {
    public String formatForDisplay(Order order) {
        return "Order: " + order.getItems().toString();
    }
    public String formatAsJson(Order order) { /* ... */ }
}

public class OrderRepository {
    public void save(Order order) { /* veritabanı mantığı */ }
    public Order findById(int id) { /* veritabanı mantığı */ }
}

public class ShippingCalculator {
    public double calculateShipping(Order order) { /* kargo kuralları */ }
}

public class OrderNotifier {
    public void sendConfirmation(Order order) { /* e-posta mantığı */ }
}

Modül D: Değişim Engelleyici #1 -- Iraksak Değişim (Divergent Change) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Kod organizasyonunu iyileştirir -- her sınıf tam olarak bir nedenle değişir
• Kod tabanı boyunca kod tekrarını azaltır
• Destek ve bakımı basitleştirir -- değişiklikler yerelleştirilir
• Tek Sorumluluk İlkesini (SRP) takip eder

Iraksak Değişim vs. Saçma Ameliyat¶

Modül D: Değişim Engelleyici #2 -- Saçma Ameliyat (Shotgun Surgery)¶

Nedir?¶

Herhangi bir değişiklik yapmak, birçok farklı sınıfta birçok küçük değişiklik yapmanızı gerektirir.

Belirtiler ve Semptomlar¶

• Tek bir mantıksal değişiklik (alan ekleme, kural değiştirme) 5'ten fazla sınıfa dokunmayı gerektirir
• Dağılmış konumlardan birinde değişiklik yapmayı sıklıkla unutursunuz
• Dağılmış sınıfların hepsi aynı endişeyle ilgilenir

Sorunun Nedenleri¶

• Tek bir sorumluluk çok sayıda sınıf arasında bölünmüştür
• Bu, Iraksak Değişim yeniden yapılandırmasının aşırı hevesli uygulanmasından sonra olabilir -- bir sınıfı çok agresif bölme
• İlgili kodun farklı yerlere taşındığı artımlı geliştirme

Referans: RefactoringGuru -- Saçma Ameliyat

Saçma Ameliyat (Diyagram)¶

Modül D: Değişim Engelleyici #2 -- Saçma Ameliyat (Shotgun Surgery) (Java Örneği -- Önce)¶

// KOKU: Saçma Ameliyat -- "phone" alanı eklemek 7+ dosya değişikliği gerektirir!
public class Customer {
    private String name;
    private String email;
    // "phone" eklemek TÜM bu sınıflarda değişiklik gerektirir:
}

public class CustomerValidator {
    public void validate(Customer c) {
        if (c.getName() == null) throw new ValidationException("Name required");
        if (c.getEmail() == null) throw new ValidationException("Email required");
        // Telefon doğrulaması da buraya eklenmeli
    }
}

public class CustomerRepository {
    public void save(Customer c) {
        String sql = "INSERT INTO customers (name, email) VALUES (?, ?)";
        // SQL telefonu dahil etmek için güncellenmeli
    }
}

public class CustomerDTO { /* Telefon eklenmeli */ }
public class CustomerMapper { /* Eşleme güncellenmeli */ }
public class CustomerView { /* Arayüz güncellenmeli */ }
public class CustomerTest { /* Testler güncellenmeli */ }
// TEK bir küçük ekleme için 7+ dosya değişti!

Modül D: Değişim Engelleyici #2 -- Saçma Ameliyat (Shotgun Surgery) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Sorumluluğu birleştir -- Metot Taşıma + Alan Taşıma
public class Customer {
    private String name;
    private String email;
    private String phone; // Yeni alan -- yalnızca bir sınıf değiştirilecek!

    public void validate() {
        if (name == null) throw new ValidationException("Name required");
        if (email == null) throw new ValidationException("Email required");
        if (phone == null) throw new ValidationException("Phone required");
    }

    public CustomerDTO toDTO() {
        return new CustomerDTO(name, email, phone);
    }
}

public class CustomerRepository {
    public void save(Customer c) {
        c.validate(); // Customer kendini doğrular
        // Kalıcılık mantığı için tek yer
    }
}

// Ortadan kaldırıldı: CustomerValidator (Customer içine satır içi yapıldı)
// Ortadan kaldırıldı: CustomerMapper (Customer.toDTO() içine satır içi yapıldı)

Modül D: Değişim Engelleyici #2 -- Saçma Ameliyat (Shotgun Surgery) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Daha iyi kod organizasyonu -- ilgili mantık bir arada yaşar
• Kod tabanı boyunca daha az kod tekrarı
• Daha kolay bakım -- değişiklikler daha az dosyaya yerelleştirilir
• Birçok dağınık konumdan birinde bir değişikliği kaçırma riskini azaltır

Ne Zaman Görmezden Gelinir¶

• Bazı çerçeveler (Spring, Jakarta EE) endişeleri kasıtlı olarak katmanlara ayırır (Controller, Service, Repository)
• Bu durumlarda, saçma ameliyat mimari netlik için kabul edilebilir bir ödünleşim olabilir

Modül D: Değişim Engelleyici #3 -- Paralel Kalıtım Hiyerarşileri (Parallel Inheritance Hierarchies)¶

Nedir?¶

Bir sınıf için alt sınıf oluşturduğunuzda, kendinizi başka bir sınıf için de alt sınıf oluşturmak zorunda bulursunuz.

Belirtiler ve Semptomlar¶

• İki sınıf hiyerarşisi eşzamanlı olarak büyür
• Bir hiyerarşiye sınıf eklemek her zaman diğerine de sınıf eklemeyi gerektirir
• Bir hiyerarşideki sınıf ön ekleri diğerindeki ön ekleri yansıtır (örn. Circle/CircleRenderer)

Sorunun Nedenleri¶

• Başlangıçta yönetilebilir sınıf yapıları, yeni sınıflar eklendikçe değiştirmesi giderek zorlaşır
• Paralellik başlangıçta o kadar küçük olabilir ki kimse fark etmez
• Bu koku aslında Saçma Ameliyatın özel bir durumudur

Referans: RefactoringGuru -- Paralel Kalıtım Hiyerarşileri

Modül D: Değişim Engelleyici #3 -- Paralel Kalıtım (Java Örneği -- Önce)¶

// KOKU: Paralel Kalıtım Hiyerarşileri
// Her yeni şekil eklediğinizde, yeni bir renderer da eklemelisiniz
public abstract class Shape {
    abstract double area();
}
public class Circle extends Shape {
    double area() { return Math.PI * radius * radius; }
}
public class Rectangle extends Shape {
    double area() { return width * height; }
}
public class Triangle extends Shape {
    double area() { return 0.5 * base * height; }
}

// Paralel hiyerarşi -- eşzamanlı büyür!
public abstract class ShapeRenderer {
    abstract void render(Shape shape);
}
public class CircleRenderer extends ShapeRenderer {
    void render(Shape shape) { /* daire çiz */ }
}
public class RectangleRenderer extends ShapeRenderer {
    void render(Shape shape) { /* dikdörtgen çiz */ }
}
public class TriangleRenderer extends ShapeRenderer {
    void render(Shape shape) { /* üçgen çiz */ }
}
// Pentagon ekle? PentagonRenderer da eklenmeli!

Modül D: Değişim Engelleyici #3 -- Paralel Kalıtım (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Metot Taşıma + Alan Taşıma -- hiyerarşileri birleştir
public abstract class Shape {
    abstract double area();
    abstract void render(); // Çizim mantığı şeklin İÇİNE taşındı
}

public class Circle extends Shape {
    private double radius;

    double area() { return Math.PI * radius * radius; }

    void render() {
        // Daire çizim mantığı (daha önce CircleRenderer'da idi)
        System.out.println("Drawing circle with radius " + radius);
    }
}

public class Rectangle extends Shape {
    private double width, height;

    double area() { return width * height; }

    void render() {
        // Dikdörtgen çizim mantığı (daha önce RectangleRenderer'da idi)
        System.out.println("Drawing rectangle " + width + "x" + height);
    }
}
// Artık paralel ShapeRenderer hiyerarşisi yok!
// Pentagon eklemek yalnızca BİR hiyerarşide değişiklik gerektirir

Modül D: Değişim Engelleyici #3 -- Paralel Kalıtım (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• İlgili hiyerarşiler arasında kod tekrarını azaltır
• Genel kod organizasyonunu ve bakım kolaylığını iyileştirir
• Yeni bir tür eklemek iki yerine bir hiyerarşide değişiklik gerektirir

Ne Zaman Görmezden Gelinir¶

• Bazen paralel sınıf hiyerarşilerine sahip olmak daha büyük tasarım sorunlarından kaçınmanın bir yoludur
• Net bir endişe ayrımı sağlıyorlarsa (örn. çizim vs. iş mantığı), haklı olabilirler
• Yeniden yapılandırma girişimleri daha çirkin kod üretiyorsa, mevcut yapıyı kabul etmek daha akıllıca olabilir

Modül D: Özet¶

Temel Noktalar -- Değişim Engelleyiciler (Change Preventers)¶

Ortak Konu¶

Değişim Engelleyiciler yazılımı katı hale getirir -- basit değişiklikler için orantısız çaba gerektirerek değişime direnir. Düzeltmeler, değişikliklerin yerelleştirilmesi için sorumlulukları yeniden düzenlemeyi içerir.

"Yeniden yapılandırma sanatı, hangi kokuların iyileştirme fırsatını gösterdiğini ve hangilerinin kabul edilebilir ödünleşimler olduğunu bilmektir." -- Martin Fowler

Modül E: Gereksizler (Dispensables)¶

Yokluğu Kodu Daha Temiz Yapacak Anlamsız ve Gereksiz Bir Şey¶

Modül E: Gereksizler (Dispensables) -- Genel Bakış¶

Gereksiz (Dispensable), yokluğu kodu daha temiz, daha verimli ve anlaşılması daha kolay yapacak olan anlamsız ve gereksiz bir şeydir.

6 Gereksiz Kokusu¶

Referans: RefactoringGuru -- Gereksizler

Modül E: Gereksiz #1 -- Yorumlar (Comments)¶

Nedir?¶

Bir metot, kodun ne yaptığını açıklamaya çalışan açıklayıcı yorumlarla doludur. En iyi yorum, bir metot veya sınıf için iyi bir addır.

Belirtiler ve Semptomlar¶

• Sonraki birkaç satırın ne yaptığını açıklayan büyük yorum blokları
• Kodu Türkçe/İngilizce olarak yeniden ifade eden yorumlar
• Kötü kodun kokusunu maskelemeye çalışan "deodorant" olarak kullanılan yorumlar
• Artık kodla uyuşmayan güncelliğini yitirmiş yorumlar

Sorunun Nedenleri¶

• Yorumlar genellikle yazar kodun sezgisel olmadığını fark ettiğinde en iyi niyetle oluşturulur
• Yorum, kötü kodun kokusunu maskelemeye çalışan bir deodorant görevi görür
• Bir kod parçasının yorumlar olmadan anlaşılamayacağını hissediyorsanız, yorumların gereksiz hale gelmesi için kod yapısını değiştirmeyi deneyin

Referans: RefactoringGuru -- Yorumlar

Modül E: Gereksiz #1 -- Yorumlar (Comments) (Java Örneği -- Önce)¶

// KOKU: Yorumlar -- kod aşırı açıklama gerektiriyor
public class PricingEngine {

    public double calculateDiscount(Customer customer, double price) {
        // Check if the customer is eligible for a premium discount
        // by verifying their membership status and purchase history.
        // A customer qualifies if they have been a member for more
        // than 2 years AND have made purchases totaling at least $1000
        // AND their account status is active.
        if ((customer.getMembershipYears() > 2) &&
            (customer.getTotalPurchases() >= 1000.0) &&
            (customer.getStatus().equals("ACTIVE"))) {
            // Apply the premium discount rate of 15%
            // This was changed from 10% in Q3 2024
            return price * 0.15;
        }
        // Apply standard discount rate of 5% for non-premium customers
        return price * 0.05;
    }
}

Modül E: Gereksiz #1 -- Yorumlar (Comments) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Metot Çıkarma + Değişken Çıkarma -- kendi kendini belgeleyen kod
public class PricingEngine {

    private static final double PREMIUM_DISCOUNT_RATE = 0.15;
    private static final double STANDARD_DISCOUNT_RATE = 0.05;

    public double calculateDiscount(Customer customer, double price) {
        if (customer.isEligibleForPremiumDiscount()) {
            return price * PREMIUM_DISCOUNT_RATE;
        }
        return price * STANDARD_DISCOUNT_RATE;
    }
}

// Customer sınıfında:
public class Customer {
    private static final int MIN_MEMBERSHIP_YEARS = 2;
    private static final double MIN_PURCHASE_AMOUNT = 1000.0;

    public boolean isEligibleForPremiumDiscount() {
        return getMembershipYears() > MIN_MEMBERSHIP_YEARS
            && getTotalPurchases() >= MIN_PURCHASE_AMOUNT
            && isActive();
    }

    public boolean isActive() {
        return "ACTIVE".equals(status);
    }
}

Modül E: Gereksiz #1 -- Yorumlar (Comments) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• Kod daha kendi kendini açıklayan ve sezgisel hale gelir
• Güncelliğini yitirmiş veya yanıltıcı yorum riskini ortadan kaldırır
• Bakım yükünü azaltır (kod değiştiğinde yorumları güncellemeye gerek yok)

Ne Zaman Görmezden Gelinir¶

• Bir şeyin NEDEN yapıldığını açıklama: // Using insertion sort because array is nearly sorted
• Sonuçları uyarma: // WARNING: Changing this order breaks the payment pipeline
• TODO yorumları: // TODO: Replace with async call after API v2 migration
• Genel API'ler için Javadoc: Parametreleri, dönüş değerlerini, istisnaları belgeleme

Modül E: Gereksiz #2 -- Tekrarlanan Kod (Duplicate Code)¶

Nedir?¶

İki kod parçası neredeyse aynı görünür. Bu en yaygın kod kokularından biridir.

Belirtiler ve Semptomlar¶

• Aynı kod yapısı birden fazla yerde küçük varyasyonlarla görünür
• Küçük değişikliklerle kopyala-yapıştır edilmiş kod
• Farklı değişken adlarıyla temelde aynı şeyi yapan iki metot

Sorunun Nedenleri¶

• Aynı anda çalışan birden fazla programcı bağımsız olarak benzer çözümler yazar
• Zaman baskısı ve teslim tarihi aciliyeti altında kopyala-yapıştır programlama
• Kodun farklı göründüğü ancak aynı işlemleri gerçekleştirdiği ince tekrarlama
• Geliştirici tembelliği veya mevcut "neredeyse doğru" kodu yeniden yapılandırma yetersizliği

Referans: RefactoringGuru -- Tekrarlanan Kod

Modül E: Gereksiz #2 -- Tekrarlanan Kod (Duplicate Code) (Java Örneği -- Önce)¶

// KOKU: Tekrarlanan Kod -- iki metotta aynı mantık
public class ReportGenerator {

    public void printOwing() {
        // Banner yazdır (TEKRARLANAN)
        System.out.println("***********************");
        System.out.println("*** Customer Owes ***");
        System.out.println("***********************");

        // Ödenmemiş tutarı hesapla (TEKRARLANAN)
        double outstanding = 0.0;
        for (Order order : orders) {
            outstanding += order.getAmount();
        }
        System.out.println("Amount: " + outstanding);
    }

    public void printStatement() {
        // Banner yazdır (TEKRARLANAN)
        System.out.println("***********************");
        System.out.println("*** Customer Owes ***");
        System.out.println("***********************");

        // Ödenmemiş tutarı hesapla (TEKRARLANAN)
        double outstanding = 0.0;
        for (Order order : orders) {
            outstanding += order.getAmount();
        }
        // ... ek beyanname mantığı
    }
}

Modül E: Gereksiz #2 -- Tekrarlanan Kod (Duplicate Code) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Metot Çıkarma -- tekrarlanan kod birleştirildi
public class ReportGenerator {

    private void printBanner() {
        System.out.println("***********************");
        System.out.println("*** Customer Owes ***");
        System.out.println("***********************");
    }

    private double calculateOutstanding() {
        return orders.stream()
            .mapToDouble(Order::getAmount)
            .sum();
    }

    public void printOwing() {
        printBanner();
        double outstanding = calculateOutstanding();
        System.out.println("Amount: " + outstanding);
    }

    public void printStatement() {
        printBanner();
        double outstanding = calculateOutstanding();
        // ... ek beyanname mantığı
    }
}

Modül E: Gereksiz #2 -- Tekrarlanan Kod (Duplicate Code) (Tedavi ve Kazanç)¶

Tedavi (Yeniden Yapılandırma Teknikleri)¶

Kazanç¶

• "Tekrarlanan kodu birleştirmek kodunuzun yapısını basitleştirir ve kısaltır"
• Hata düzeltmelerinin birden fazla yerde değil yalnızca bir kez uygulanması gerekir
• Anlaşılması daha kolay ve bakımı daha ucuz kod

Ne Zaman Görmezden Gelinir¶

• Çok nadir durumlarda, aynı iki kod parçasını birleştirmek kodu daha az sezgisel yapabilir
• Test kodunda, testleri netlik için bağımsız ve tekrarlı tutmak bazen kabul edilebilir

Modül E: Gereksiz #3 -- Tembel Sınıf (Lazy Class)¶

Nedir?¶

Varlığını haklı çıkarmak için çok az iş yapan bir sınıf. Sınıfları anlamak ve bakımını yapmak her zaman zaman ve para maliyetine sahiptir. Bu nedenle bir sınıf dikkatinizi hak edecek kadar iş yapmıyorsa, silinmelidir.

Belirtiler ve Semptomlar¶

• Sınıf çok az metot veya alana sahiptir
• Sınıf tek bir değeri sarmaktan fazlasını yapmaz
• Diğer sınıflar bu sınıfın verileriyle tüm gerçek işi yapar

Sorunun Nedenleri¶

• Bir sınıf, yeniden yapılandırma orijinal işlevselliğini azalttıktan sonra gülünç derecede küçük olabilir
• Ya da hiç gerçekleşmeyen gelecekteki geliştirmeyi desteklemek için tasarlanmıştır
• Ya da çok agresif bir Sınıf Çıkarma yeniden yapılandırmasından oluşturulmuştur

Referans: RefactoringGuru -- Tembel Sınıf

Modül E: Gereksiz #3 -- Tembel Sınıf (Lazy Class) (Java Örneği -- Önce)¶

// KOKU: Tembel Sınıf -- neredeyse hiçbir şey yapmıyor
public class PhoneNumber {
    private String number;

    public String getNumber() {
        return number;
    }

    public void setNumber(String number) {
        this.number = number;
    }
    // Bu kadar. Doğrulama yok, biçimlendirme yok, hiç mantık yok.
}

public class Customer {
    private String name;
    private PhoneNumber phone; // Sarmalayıcı hiçbir değer katmıyor

    public String getPhoneNumber() {
        return phone.getNumber();
    }

    public void setPhoneNumber(String number) {
        phone.setNumber(number);
    }
}

Modül E: Gereksiz #3 -- Tembel Sınıf (Lazy Class) (Java Örneği -- Sonra)¶

// YENİDEN YAPILANDIRILMIŞ: Satır İçi Sınıf -- tembel sınıfı kullanıcısına birleştir
public class Customer {
    private String name;
    private String phone; // Basit alan, sarmalayıcıya gerek yok

    public String getPhone() { return phone; }
    public void setPhone(String phone) { this.phone = phone; }
}

// ALTERNATİF: PhoneNumber VAR OLMALI ise, ona gerçek davranış verin
public class PhoneNumber {
    private String areaCode;
    private String number;

    public PhoneNumber(String rawNumber) {
        validate(rawNumber);
        parse(rawNumber);
    }

    private void validate(String rawNumber) {
        if (!rawNumber.matches("\\d{3}-\\d{4}"))
            throw new IllegalArgumentException("Invalid phone number");
    }

    public String format() {
        return "(" + areaCode + ") " + number;
    }
    // Artık PhoneNumber hak ediyor!
}