Skip to content

Latest commit

 

History

History
119 lines (77 loc) · 7.4 KB

ArchitecturalDesignPattern.md

File metadata and controls

119 lines (77 loc) · 7.4 KB

5-ая часть содержит вопросы и ответы дизайна и паттернов проектирования архитектуры iOS приложений.

Расскажите об MVVM

MVVM(Model–View–ViewModel) - это архитектурный паттерн проектирования программного обеспечения, который позволяет отделить разработку графического интерфейса пользователя (представление/вью) от разработки бизнес-логики или внутренней логики (модель), чтобы View не зависело от какой-либо модели.

Компоненты MVVM паттерна:

1. Model

Представляет собой логику работы с данными и описание фундаментальных данных, необходимых для работы приложения.

2. View

Графический интерфейс (в контексте iOS — вьюхи) (окна, списки, кнопки и т. п.). Выступает подписчиком на событие изменения значений свойств или команд, предоставляемых ViewModel. В случае, если в ViewModel изменилось какое-либо свойство, то она оповещает всех подписчиков об этом, и View, в свою очередь, запрашивает обновлённое значение свойства из ViewModel.

3. ViewModel

Обёртка данных из модели, подлежащих связыванию. То есть, ViewModel содержит Model, преобразованную к View, а также команды, которыми может пользоваться View, чтобы влиять на Model.

Расскажите об Singleton pattern

Singleton pattern — паттерн разработки ПО, в котором существует единственный инстанс некоторого класса, предоставляющий глобальную точку доступа к одному (single) инстансу:

let calendar = Calendar.current
let weatherInstance = WeatherService.shared
let userDefaults = UserDefaults.standart

Реализация в Swift:

class AsyncLocalNotifications {
  private init() {}
  static let instance = Self()
}

// применимо к структурам
struct Settings {
  private init() {}
  static let shared = Self()
}

Как видно, данный паттерн легко реализовать.

Singleton убивает основную идею разделения, т.к. доступен глобально и делает код завязанным на инстансе, что в свою очередь затрудняет юнит тестирование.

Какой подход лучше Singleton?

Inversion of control (IoC) и Dependency injection паттерны, которые решают проблему singleton.

Расскажите об Dependency Injection

Dependency Injection (DI) — механизм внедрения зависимостей. Данная техника облегчает разработку и тестирование, т.к. мы можем сделать несколько различных сервисов.

Зависимости может быть внедрена несколькими способами, с помощью инъекции в конструктор или сеттер.

Расскажите об Decorator design pattern

Декоратор — структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту. В отличие от наследование, объекты декоратора не ограниченны родительскими классами. В swift данный паттерн достигается с использованием протоколов.

Расскажите об Anti-pattern

Anti-pattern (Антипаттерн) - это распространённый подход к решению класса часто встречающихся проблем, являющийся неэффективным, рискованным или непродуктивным. Известны тем, что их использование даёт негативные последствия. Иногда singleton считается антипаттерном из-за неправильного использования.

Расскажите об Observer pattern

Observer pattern (наблюдатель) - поведенческий шаблон проектирования. Реализует у класса механизм, который позволяет объекту этого класса получать оповещения об изменении состояния других объектов и тем самым наблюдать за ними. В swift данный паттерн реализуется с помощью Notifications и Key-Value Observing.

SOLID

В разработке программного обеспечения SOLID — это акроним пяти принципам проектирования, призванных сделать проекты программного обеспечения более понятными, гибкими и удобными в поддержке.

S: single responsibility principle

Принцип единственной ответственности. Для каждого класса должно быть определено единственное назначение.

O: open-closed principle

Принцип открытости/закрытости. Программные сущности должны быть открыты для расширения, но закрыты для модификации.

L: Liskov substitution principle

Принцип подстановки Лисков. Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.

I: interface segregation principle

Принцип разделения интерфейса. Клиенты не должны зависеть от интерфейсов, которые они не используют.

D: dependency inversion principle

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