Какие знаешь принципы проектирования?

Принципы проектирования (Design Principles)

Принципы проектирования — это фундаментальные рекомендации и лучшие практики, которые помогают создавать поддерживаемый, гибкий и масштабируемый код. В iOS-разработке они особенно важны из-за долгого жизненного цикла приложений, частых обновлений платформы и необходимости работы в команде. Их можно разделить на общие принципы объектно-ориентированного проектирования (ООП) и специфические для архитектур iOS.

Ключевые принципы SOLID

SOLID — это акроним пяти основных принципов, популяризированных Робертом Мартином.

1. S — Single Responsibility Principle (Принцип единственной ответственности)

    Класс должен иметь только одну причину для изменения. Например, в iOS:

```swift
// ПЛОХО: Класс занимается и логикой, и работой с сетью, и сохранением.
class UserManager {
    func fetchUser() { /* сетевой запрос */ }
    func saveToDatabase() { /* работа с CoreData */ }
    func validateEmail() { /* логика валидации */ }
}

// ХОРОШО: Ответственности разделены.
class NetworkService {
    func fetchUser() { /* сетевой запрос */ }
}
class DatabaseService {
    func save(user: User) { /* работа с CoreData */ }
}
class UserValidator {
    func validate(email: String) -> Bool { /* логика */ }
}
```

2. O — Open/Closed Principle (Принцип открытости/закрытости)

    Сущности должны быть открыты для расширения, но закрыты для модификации. В Swift это реализуется через **протоколы** и **наследование**.

```swift
protocol PaymentMethod {
    func processPayment(amount: Double)
}

class CreditCardPayment: PaymentMethod {
    func processPayment(amount: Double) { /* логика для карты */ }
}

class ApplePayPayment: PaymentMethod {
    func processPayment(amount: Double) { /* логика для Apple Pay */ }
}

class PaymentProcessor {
    func process(payment: PaymentMethod, amount: Double) {
        payment.processPayment(amount: amount) // Не нужно менять код процессора для добавления нового способа
    }
}
```

3. L — Liskov Substitution Principle (Принцип подстановки Барбары Лисков)

    Объекты базового класса должны быть заменяемы объектами производных классов без изменения корректности программы. Нарушение ведет к неожиданным сбоям.

```swift
// Нарушение: Квадрат, наследующийся от прямоугольника, ломает логику, если меняет и ширину, и высоту одновременно.
class Rectangle {
    var width: Double = 0
    var height: Double = 0
    var area: Double { width * height }
}

class Square: Rectangle {
    override var width: Double {
        didSet { height = width } // Побочный эффект, нарушающий контракт родителя
    }
}
```

4. I — Interface Segregation Principle (Принцип разделения интерфейса)

    Клиенты не должны зависеть от методов, которые они не используют. В Swift вместо одного "толстого" протокола лучше создавать несколько специализированных.

```swift
// ПЛОХО: Протокол заставляет реализовывать ненужные методы.
protocol Worker {
    func code()
    func test()
    func design()
    func deploy()
}

// ХОРОШО: Интерфейсы разделены.
protocol Developer {
    func code()
}
protocol Tester {
    func test()
}
class iOSDeveloper: Developer { // Реализует только нужное
    func code() { /* ... */ }
}
```

5. D — Dependency Inversion Principle (Принцип инверсии зависимостей)

    Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

```swift
// Зависимость от абстракции (протокола), а не от конкретного сервиса.
protocol DataServiceProtocol {
    func fetchData() -> [String]
}

class NetworkService: DataServiceProtocol {
    func fetchData() -> [String] { /* ... */ }
}

class ViewModel {
    let service: DataServiceProtocol // Внедрение зависимости через протокол
    init(service: DataServiceProtocol) {
        self.service = service // Это позволяет легко подменить реализацию, например, на мок для тестов
    }
}
```

Другие важные принципы в iOS

• DRY (Don't Repeat Yourself — Не повторяйся): Избегание дублирования кода через вынесение общей логики в функции, базовые классы или расширения (extensions).

  // Дублирование:
  button1.layer.cornerRadius = 8
  button2.layer.cornerRadius = 8
  
  // Следуя DRY:
  extension UIView {
      func roundCorners(radius: CGFloat) {
          layer.cornerRadius = radius
          clipsToBounds = true
      }
  }
  button1.roundCorners(radius: 8)
  button2.roundCorners(radius: 8)
  

• KISS (Keep It Simple, Stupid — Делай проще): Предпочтение простых, понятных решений сложным. Избыточное использование сложных паттернов там, где можно обойтись UIViewController, — нарушение KISS.

• YAGNI (You Ain't Gonna Need It — Тебе это не понадобится): Не добавляй функциональность "на вырост". Реализуй только то, что требуется прямо сейчас, чтобы не перегружать код.

• Composition over Inheritance (Композиция над наследованием): Предпочтение композиции объектов (включение одного объекта в другой) глубоким иерархиям наследования. Это повышает гибкость и тестируемость. Swift и SwiftUI активно поощряют этот подход через протоколы и модификаторы.

• Principle of Least Knowledge (Закон Деметры, "Не разговаривай с незнакомцами"): Объект должен иметь как можно меньше знаний о структуре и свойствах других объектов. Это уменьшает связанность.

  // ПЛОХО: ViewController знает слишком много о внутреннем устройстве engine.
  let speed = car.engine.throttle.valve.position * 10
  
  // ХОРОШО: Запрос абстрагирован.
  let speed = car.currentSpeed
  

Применение в iOS-архитектурах

Эти принципы лежат в основе популярных архитектур, таких как MVC (Model-View-Controller), MVVM (Model-View-ViewModel), VIPER и Clean Architecture.

• MVVM, например, напрямую реализует Dependency Inversion (ViewModel зависит от абстрактного ModelService) и Single Responsibility (разделение логики представления и данных).
• Использование протоколов в Swift — главный инструмент для соблюдения Open/Closed и Dependency Inversion.

Вывод: Знание и грамотное применение этих принципов отличает senior-разработчика от junior. Они не являются догмой, но служат "компасом" для принятия архитектурных решений, позволяя создавать код, который легко тестировать, рефакторить и поддерживать на протяжении многих лет, что критически важно для успешного iOS-приложения.