# 01. Design Patterns Kirish: G'isht vs Bino (Patterns vs Architecture)

> "Dasturiy injiniringda eng xavfli dasturchi — bu barcha 23 ta Gang of Four patternlarini yodlab olib, ularning barchasini bitta oddiy 'Salom Dunyo' ilovasiga tiqishga urinayotgan dasturchidir. Senior dasturchi patternni qachon ishlatishni emas, qachon **ishlatmaslikni** biladi."

---

## 1. G'oya: Pattern (Andoza) va Architecture (Arxitektura) Farqi

Ko'pgina junior va middle dasturchilar "Design Pattern" va "Architecture" tushunchalarini chalkashtirib yuborishadi.

Keling, binokorlik metaforasi bilan tushunamiz:
* **Design Pattern (Andoza):** Bu alohida bir muammoni hal qiluvchi **g'isht, eshik qulfi yoki deraza romi**. Masalan, ikkita mos kelmaydigan simni ulash uchun `Adapter` ishlatasiz, yoki faqat 1 ta kaliti bor eshik uchun `Singleton` qurasiz.
* **Architecture (Arxitektura):** Bu binoning **bosh rejasi (chizmasi)**. Oshxona qayerda, mehmonxona qayerda, elektr tarmog'i qanday o'tgan (MVVM, VIPER, Clean Architecture, The Composable Architecture — TCA).

```mermaid
graph TD
    subgraph Architecture["Arxitektura: Butun Bino Rejasi (MVVM / Clean)"]
        direction TB
        View["Presentation Layer (SwiftUI View)"]
        VM["Business Logic (ViewModel)"]
        Domain["Domain Layer (Use Cases)"]
        Data["Data Layer (Repository)"]

        View --> VM
        VM --> Domain
        Domain --> Data
    end

    subgraph Patterns["Design Patterns: Har Bir Qavatdagi G'ishtlar"]
        direction TB
        P1["Coordinator: Navigatsiyani boshqaradi"]
        P2["Observer: View va VM'ni reaktiv bog'laydi"]
        P3["Strategy: To'lov usullarini almashtiradi"]
        P4["Factory: Murakkab entity'larni yasaydi"]
        P5["Adapter: Eski SDK larni ulaydi"]
    end

    Architecture -.->|"Ichida qo'llaniladi"| Patterns

    style Architecture fill:#131720,stroke:#7da2ce,stroke-width:2px
    style Patterns fill:#131720,stroke:#bef264,stroke-width:2px
```

Siz bitta MVVM arxitekturasidagi loyihada `Coordinator`, `Factory`, `Observer`, `Strategy` va `Repository` patternlarini bir vaqtda ishlatasiz!

---

## 2. Gang of Four (GoF) Patternlarining 3 Ta Asosiy Oilasi

1994-yilda 4 nafar olim (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) dasturiy ta'minotdagi takrorlanuvchi 23 ta klassik andozani 3 ta toifaga ajratishgan:

```mermaid
mindmap
  root((iOS Design Patterns))
    Creational["1. Creational (Yaratuvchi)\nObyekt yaratishni xavfsiz va moslashuvchan qilish"]
      Singleton["Singleton\n(Yagona nusxa)"]
      FactoryMethod["Factory Method\n(Protokolli yasovchi)"]
      AbstractFactory["Abstract Factory\n(Oilaviy fabrikalar)"]
      Builder["Builder\n(Bosqichma-bosqich)"]
      Prototype["Prototype\n(Klonlash va CoW)"]
    Structural["2. Structural (Tuzilmaviy)\nSinflar va obyektlarni bir-biriga ulash"]
      Adapter["Adapter\n(Interfeys moslashtirish)"]
      Decorator["Decorator\n(Qo'shimcha xatti-harakat)"]
      Facade["Facade\n(Soddalashtirilgan API)"]
      Composite["Composite\n(Daraxtsimon tuzilma)"]
      Proxy["Proxy\n(Kesh va himoya)"]
    Behavioral["3. Behavioral (Xulq-atvor)\nObyektlar o'rtasida ma'lumot va harakat almashish"]
      Observer["Observer\n(Kuzatuvchi / Combine)"]
      Strategy["Strategy\n(Dinamik algoritmlar)"]
      Command["Command\n(Undo / Redo / Navbat)"]
      StatePattern["State\n(Holat mashinasi)"]
      ChainOfResp["Chain of Responsibility\n(Interceptorlar)"]
```

---

## 3. SOLID Tamoyillari Bilan Aloqasi

Har bir to'g'ri qo'llanilgan design pattern ortida Robert C. Martin'ning **SOLID** tamoyillari yotadi:

| SOLID Tamoyili | Qaysi Patternlar Bilan Bog'liq? | Muammo va Yechim |
| :--- | :--- | :--- |
| **S (Single Responsibility)** | `Facade`, `Coordinator` | `UIViewController` ham UI chizib, ham navigatsiya qilib, ham tarmoq so'rovini yubormasligi kerak |
| **O (Open / Closed)** | `Strategy`, `Decorator`, `Factory` | Yangi to'lov usuli (masalan Apple Pay) qo'shilganda eski `switch-case` kodiga tegmasdan yangi sinf yozish |
| **L (Liskov Substitution)** | `Factory Method`, `Adapter` | Ota sinf o'rniga bolasi qo'yilganda dastur qulamasligi |
| **I (Interface Segregation)** | `Delegation`, Protocol Composition | 50 ta metodi bor gigant protokollar o'rniga kichik, maxsus protokollar |
| **D (Dependency Inversion)** | `Dependency Injection`, `Repository` | Yuqori qatlam (ViewModel) quyi qatlam (URLSession) ga to'g'ridan-to'g'ri bog'lanmasligi, protokol orqali ishlashi |

---

## 4. "Patternitis" Qopqoni: Overengineering Nega Xavfli?

Dasturchilar hayotida 3 ta bosqichni bosib o'tishadi:

```
[Dasturchining Fikrlash Evolyutsiyasi]
Junior:  "Pattern nima ekanini bilmayman, hamma kodni ViewController ichiga tiqaman (MVC)."
Middle:  "Men barcha patternlarni o'rgandim! Endi har bir Label yaratish uchun ham AbstractFactory,
          har bir tugma uchun Command, har bir raqam uchun Strategy quraman!" (OVERENGINEERING!)
Senior:  "Eng oddiy va tushunarli yechim — eng yaxshi yechimdir. Muammo paydo bo'lmaguncha
          arxitekturani keraksiz murakkablashtirmayman (KISS & YAGNI)."
```

### Haqiqiy Holat (Case Study):
Bir startapda dasturchi oddiy 2 ta ekrandan iborat ToDo ro'yxat ilovasi uchun `AbstractFactory`, `Proxy`, `Command` va `Builder` patternlarini qo'llab, 40 ta ortiqcha fayl yaratgan. Yangi stajyor kelganda 1 ta oddiy checkbox o'zgarishini qilish uchun 6 ta turli faylni o'zgartirishiga to'g'ri kelgan. Bu sof **Anti-Pattern** vaqt o'g'irlashidir!

---

## 5. Interaktiv Savol-Javob (Self-Check Quiz)

<details>
<summary><b>1-Savol: Nega Swift struct'lari bilan ishlaganda ko'plab an'anaviy GoF patternlari (masalan Prototype yoki Decorator) o'z dolzarbligini qisman yo'qotadi?</b> (Yechimni ko'rish uchun bosing)</summary>

**Tahlil va Yechim:**
GoF kitobi 1994-yilda C++ va Smalltalk (Reference Type / Class asosidagi tillar) uchun yozilgan. Swift'da esa `struct`lar **Value Type** hisoblanadi. 
1. `Prototype` patternida obyektni nusxalash (`clone`) talab qilinar edi — Swift structlarida bu tilning o'zida `let newObj = oldObj` orqali tekinga va xotiradan yengil (Copy-on-Write) amalga oshadi.
2. `Decorator` patterni o'rniga Swift'da `extension`lar yoki SwiftUI'ning `ViewModifier`lari ishlatiladi.
</details>

<details>
<summary><b>2-Savol: Loyihangizda arxitekturani qachon Refactoring qilib patternga o'tkazish kerak?</b> (Yechimni ko'rish uchun bosing)</summary>

**Tahlil va Yechim:**
"Uchtalik Qoidasi" (Rule of Three): Kodda bir xil mantiqiy takrorlanish yoki moslashuvchanlik ehtiyoji **kamida 3 marta** takrorlanganda pattern qo'llaniladi. Bir martalik oddiy kodga oldindan murakkab pattern qurish — bu kelajakdagi xatolar uchun zamin yaratishdir (Premature Optimization).
</details>

---

## 6. Amaliy Topshiriq

O'z joriy loyihangizdagi eng katta ViewController yoki View faylini oching:
1. Undagi mas'uliyatlarni sanab chiqing (UI chizish, tarmoq chaqiruvi, navigatsiya, xatoliklarni alertda ko'rsatish).
2. Qaysi mas'uliyatni qaysi pattern yordamida (`Coordinator`, `Repository`, `Service`) alohida qatlamga chiqarish mumkinligini qog'ozga chizib oling!

*(Keyingi darslarda biz har bir patternni noldan, to'liq kodlari va xotira tahlili bilan amalda ko'ramiz!)*