> For the complete documentation index, see [llms.txt](https://bekoturko.gitbook.io/yazilim-gelistirme-wiki/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bekoturko.gitbook.io/yazilim-gelistirme-wiki/yazilim-gelistirme-kilavuzu/refactoring/simplifying-conditional-expressions.md).

# Simplifying Conditional Expressions

Koşullu İfadeleri Sadeleştirmek - Simplifying Conditional Expressions

## Koşullu İfadeleri Sadeleştirmek - [Simplifying Conditional Expressions](https://sourcemaking.com/refactoring/simplifying-conditional-expressions)

Koşullu ifadelerin zamanla daha fazla karmaşık bir mantığa sahip olma eğilimleri vardır. Bu durumla da başetmek için yöntemler bulunur.\
Kodun karmaşıklaşmasına en fazla etkisi olan bölümler koşullu ifadeler ve döngü yapılarıdır. Bu kod blokları basitleştirilmeli, kolay anlaşılabilir ve yönetilebilir hale getirilmelidir.

### [Decompose Conditional](https://sourcemaking.com/refactoring/decompose-conditional)

* Dallanma mantığını anlaşılır ve daha kolay yönetilebilir hale getirir.
* Yöntem: Koşulu, başarı bloğunu ve diğer durum bloklarını metotlara çevir.
* Programın en karmaşık olduğu yerler bu bölümlerdir.
* Koşulların
  * ne üzerinden dallara ayrıldığı anlaşılır.
  * testlerini yazmak kolaylaşır.
  * koşullara ait kod parçalarının yönetimi kolaylaşır.
* Okuyan kişi koşulları çözümleyip anlamak zorunda bırakılmamalı (Kodu kafasında derleyip çalıştırmak zorunda bırakılmamalı. Bu işlemleri yapan kişinin beynindeki gri hücre sayısı hızla azalır.)
* Koşulları anlatacak şekilde isimlendirilen metotların çağrıları okunduğunda koşullu ifadenin ne yaptığı anlaşılır olmalı.

| **KOŞULLARI VE KOŞULLARA GÖRE ÇALIŞAN KOD BLOKLARINI METOTLARA ÇEVİR.** |
| ----------------------------------------------------------------------- |

**NOT:**\
Nesne yönelimli programlarda koşullu ifadeler azdır. (switch ifadelerine nadiren rastlanır.)\
Koşullu davranışları **polimorfizm** yönetir. Böylece

* İstemci koşulları bilmek zorunda kalmaz.
* Koşulları arttırmak (veya azaltmak) kolaylaşır.

### [Consolidate Conditional Expression](https://sourcemaking.com/refactoring/consolidate-conditional-expression)

**Semptom**\
Aynı sonucu veren koşul kontrolleri var.

**Çözüm**\
Koşul ifadelerini tek ifade olarak grupla ve metoda çevir.

**Uyarı**\
Koşulların birleştirilmesi zorlama ve anlamsızsa yapma.

**Öneri (SVG):**\
İki farklı kontrolü daha soyut düzeyde isimlendirerek gruplamak işlemi kolaylaştırır.

### [Consolidate Duplicate Conditional Fragments](https://sourcemaking.com/refactoring/consolidate-duplicate-conditional-fragments)

**Semptom**\
Aynı kod parçası koşul ifadelerinin her dalında var.**Çözüm**

* Kod parçasını koşul kontrollerinin dışına çıkar. (Başa veya sona yerleştir.)
* Tekrar eden ifade birden fazla satırda oluşuyorsa ifadeleri metoda çevir.

**Not**\
Tekrar eden kodun içerdiği değerlerin, koşul bloklarında değiştirilmediğinden emin olunmalı.

**Öneri (SVG)**\
`try-catch` bloklarında da uygulanabilir. `finally` bölümüne taşınabilir.

### [Remove Control Flag](https://sourcemaking.com/refactoring/remove-control-flag)

**Semptom**\
Bir dizi koşul kontrolü (`bool`) için kontrol değeri olarak kullanılan bir değişken var.

**Çözüm**\
Değişken kullanmak yerine `break` veya `return` ifadelerini kullan.

* Metotlarda sadece bir çıkış ifadesi kullanmak Structured Programming döneminden kalan bir alışkanlık. (Artık metotlardan bir çıkış noktası olmak zorunda değil. Bu şekilde kullanım kodu karmaşıklaştırıyor.)
* `break, continue` gibi anahtar kelimeler bu tip kullanımlar için var.
* Değişken, kullanıldığı kod blokları boyunca yaşıyor, herhangi bir andaki durumunu tespit etmek ve güvence altına almak zor.
* İlgili koşul kontrolü sonrasında gerekli işlem hemen uygulanınca koşullu ifadenin **amacı** ve **çıktısı** daha kolay anlaşılır hale gelir.

**Not**\
Kontrol değişkeninin sonuç bilgisi içerip içermediğine dikkat edilmeli. Eğer öyleyse değişken kullanılmaya devam edilmeli.

### [Replace Nested Conditionals with Guard Clauses](https://sourcemaking.com/refactoring/replace-nested-conditional-with-guard-clauses)

**Semptom**\
Normal akışın açık bir şekilde görünmesini engelleyen, onu gizleyen koşullu davranış kontrolleri var.

**Çözüm**\
Özel durumlar için guard clause kullan. (Normal akışı yalnız bırak.)**Not**\
İki türlü koşullu ifade var:

1. Her dalın normal davranış olduğu
2. Bir dalın normal davranış, diğerlerinin istisna olduğu

Farklı niyetler → Kodda gözle görülür hale getirilmeli.

1\. durumda `if-else` kullan.\
2\. durumda kontrol et ve return ile çık. (Guard clause / Kent Beck)

| **Hedef → VURGU** |
| ----------------- |

* `if-then-else` her dalın aynı ağırlığa sahip olduğu hissini verir. (Okuyucu böyle düşünür.)
* Guard clause: “Bu durum nadir bir durum, eğer gerçekleşirse bir şey yap ve çık.”
* Yine metotlarda tek giriş - **tek çıkış** noktası olması beklentisinden kaynaklanır. (Tek çıkış o kadar da yararlı değil. Önemli olan **açıklık - clarity**)
* Normal akış maskelenir, indentler artar:
  * …….
    * …….
      * …….
        * *normal akış*
      * …….
    * …….
  * …….
* Metotla ilgim kalmadığında, bunu metottan çıkarak belli ederim.
* Sonuç görünür (explicit) olur, kolayca anlaşılır. (Mesela sonuç bir değişkenin o anki değeri olmaz.)

### [Replace Conditionals with Polymorphism](https://sourcemaking.com/refactoring/replace-conditional-with-polymorphism)

**Semptom**\
Nesnenin tipine göre farklı bir davranış seçen koşullu bir ifade var.

**Çözüm**\
Her dalı, ana sınıfa, alt sınıfta override edilen bir metot olarak ekle.**Yararları**

* Yeni tip eklemek kolaydır.
  1. Yeni alt sınıf ekle.
  2. Override edilen metodu implemente et.
* Aksi halde tüm koşullu ifadeleri bulup güncellemek (yeni tipe ait kontrolleri ve kod bloklarını eklemek) gerekir.
* İstemci alt sınıflar ve koşullar hakkında bir şey bilmek zorunda kalmaz. (Sadece istediği metodu çağırır.)
* Sistemin bağımlılıklarını azaltır.
* Güncellemeyi daha kolay hale getirir.

**Yöntem**

1. **Replace Type Code with Subclasses**
   * Değişmez ve davranışı etkileyen bir tip kodu var.
   * Tip kodunu alt sınıf ile değiştir.
2. **Replace Type Code with State/Strategy**
   * Nesne oluşturulduktan sonra tip kodu değişirse
   * Tip kodu zaten önceden başka bir nedenle alt sınıfa çevrildiyse
   * Alt sınıflar ile çözülmez, State / Strategy kullanmak gerekir.