Архитектура

Проектирование:

  1. Концептуальная модель - концепция, диаграмма модулей.
  2. Интерфейсная модель - спецификация, диаграмма классов.
  3. Реализация.

Слои архитектуры:

  • view - слой представления;
  • controller - слой управления;
  • service - слой бизнес-логики;
  • repository - слой хранения данных.

Пакеты:

  • model - классы, описывающие данные (например, игровое поле);
  • component - классы, описывающие бизнес-логику.

Виды интеграции:

  • шаринг файловой системы (отчеты, выгрузки, Big data);
  • шаринг базы данных;
  • вызов процедур;
  • вызов методов;
  • мессенджер (очередь сообщений).

Архитектура веб-приложения
Чистая архитектура для веб-приложения
Создание архитектуры программы

Объекты проектирования:

  • Entity - реальные объекты;
  • Boundary - граничные объекты = интерфейсы;
  • Control - координаторы.

Парадигмы ООП:

  • абстракция - каркас (бывает концептуальная и интерфейсная);
  • инкапсуляция - сокрытие типов данных, сокрытие реализации, сокрытие частей программы;
  • наследование - отношение "is a";
  • полиморфизм (как следствие наследования);
  • композиция - отношение "has a";
  • посылка сообщений - информационные потоки;
  • повторное использование.

Виды отношений:

  • ассоциация - свободное партнерство между объектами (вызов передается через параметр метода);
  • агрегация - объект может содержать другой объект (объявляется поле + метод добавления);
  • композиция - объект не может существовать без другого объекта (объявляется поле + инициализация через конструктор).

Порядок решения задачи:

  • чтение исходных данных задачи;
  • алгоритм обработки исходных данных для получения результата (последовательность действий);
  • отображение результата.

CoderLessons.comRefactoring.guru

Порождающие
(отвечают за создание объектов)


Фабричный метод (виртуальный конструктор)
создание объекта через метод.

Фабрика
создание семейства объектов объединенных общим признаком (набор мебели в стиле борокко, в стиле рококо, в современном стиле).

Одиночка
создание объекта в единственном экземпляре.

Прототип
создание копии объекта (клонирование). Используется для сложных / высокозатратных объектов.

Строитель (дополнение, как часть объекта или дополнительная опция)
создание объекта через цепочку вызова методов. Используется для удобства, когда объект создается с переменным количеством параметров (проверяется предлогом "с" - суп с картошкой, с морковкой, с мясом). Похож на Декоратор, отличие в моменте создания готового объекта.

Структурные
(отвечают за построение удобных в поддержке иерархий классов)


Адаптер
соединяет объекты для совместной работы через изначально несовместимые интерфейсы.

Мост
объединяет две иерархии (фигура - цвет).

Компоновщик
позволяет сгруппировать множество объектов в древовидную структуру, а затем работать с ней так, как будто это единичный объект (договор = доп соглашение, акт, штраф), (заказ = товар1, товар2, товар3; товар1= т1,т2).

Декоратор (дополнительная опция)
позволяет динамически добавлять объектам новую функциональность, оборачивая их в полезные «обёртки». Похож на Строитель, отличие в моменте создания готового объекта.

Фасад
предоставляет простой интерфейс к сложной системе классов, библиотеке или фреймворку.

Легковес (кеширование - повышение производительности за счет повторного использования созданного объекта)
позволяет вместить бóльшее количество объектов в отведённую оперативную память. Легковес экономит память, разделяя общее состояние объектов между собой, вместо хранения одинаковых данных в каждом объекте.

Заместитель (proxy - оболочка / облегченная версия объекта / защита объекта)
позволяет подставлять вместо реальных объектов специальные объекты-заменители. Эти объекты перехватывают вызовы к оригинальному объекту, позволяя сделать что-то до или после передачи вызова оригиналу.
Платёжная карточка — это заместитель пачки наличных. И карточка, и наличные имеют общий интерфейс — ими можно оплачивать товары. Для покупателя польза в том, что не надо таскать с собой тонны наличных, а владелец магазина рад, что ему не нужно делать дорогостоящую инкассацию наличности в банк — деньги поступают к нему на счёт напрямую..

Поведенческие
(решают задачи эффективного и безопасного взаимодействия между объектами программы)


Цепочка обязанностей (иерархическая обработка запросов)
позволяет передавать запросы последовательно по цепочке обработчиков. Каждый последующий обработчик решает, может ли он обработать запрос сам и стоит ли передавать запрос дальше по цепи (например, обработка исключений).

Команда (повтор-отмена запросов)
превращает запросы в объекты, позволяя передавать их как аргументы при вызове методов, ставить запросы в очередь, логировать их, а также поддерживать отмену операций.

Интерпретатор (преобразование)
разбирает синтаксис языка (например, генератор отчетов, компилятор, sql запросы).

Итератор (for-each)
даёт возможность последовательно обходить элементы составных объектов, не раскрывая их внутреннего представления.

Посредник (диспетчер / контроллер)
позволяет уменьшить связанность множества классов между собой, благодаря перемещению этих связей в один класс-посредник.

Снимок (хранитель внутреннего состояния объекта)
позволяет сохранять и восстанавливать прошлые состояния объектов, не раскрывая подробностей их реализации.

Наблюдатель (отслеживание обновлений)
создаёт механизм подписки, позволяющий одним объектам следить и реагировать на события, происходящие в других объектах (например, подписка на новости).

Состояние (торговый автомат)
позволяет объектам менять поведение в зависимости от своего состояния. Извне создаётся впечатление, что изменился класс объекта.

Стратегия (выбор алгоритма)
определяет семейство схожих алгоритмов и помещает каждый из них в собственный класс, после чего алгоритмы можно взаимозаменять прямо во время исполнения программы (например, сохранение файла в разных форматах, выполнение различных алгоритмов сортировки).

Шаблонный метод (описывает общий алгоритм)
определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Паттерн позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры.

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

Information Expert
информация должна обрабатываться тем объектом, в котором эта информация находится.

Creator
объект создается в том классе, в котором он непосредственно нужен для использования.

Controller
преобразование многопоточного ввода в однопоточное обращение к объектам системы.

Low Coupling
классы должны иметь минимально необходимое количество связей между собой. Чем меньше связей, тем стабильней система.

High Cohesion
функционал объекта должен быть максимально связан между собой по смыслу. Разнородные части - отдельные объекты.

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

Pure Fabrication (искусственный)
использовать для уменьшения связей, как фасад / посредник.

Inderection (инверсия зависимостей)
обращение к классу должно идти через его интерфейс. Интерфейс является принадлежностью не тех классов, которые его имплементируют, а тех классов, которые его вызывают
А ⟶ B ⟹ (A ⟶ IB) + (B ⟶ IB)

Protected Variations (защита от изменений)
следовать вышеперечисленным принципам.

SOLID - менеджмент зависимостей, характеризирует отношения и операции между объектами.

  • S — единственная ответственность.
  • O — открыт к расширению и закрыт к изменению.
  • L — наследник не должен изменять поведение базового класса (родителя).
  • I — множество интерфейсов лучше одного универсального.
  • D — абстракция не должна зависеть от реализации.

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

Свойства объекта позволяют ему определять свое состояние, а программный код объекта обеспечивает его корректное функционирование (т.е. выполнение тех действий, для которых он, собственно, предназначен).

Объекты одного типа (класса) содержат различные данные, но обладают одинаковым поведением.

DRY - не повторяйся.

KISS - не усложняй, пиши проще, декомпозируй.

YAGNI - не пиши прозапас. Реализовуй то, что нужно сейчас.

SoC - разделяй ответственность. Рразделяй систему на слои (UI, бизнес логика, презентационная логика, слой БД).

CQS - разделяй запросы и команды. Каждый метод должен быть либо командой, либо запросом, но не тем и другим одновременно.

LoD (закон Деметры) - каждый элемент системы должен иметь ограниченные знания о других элементах (не разговаривай с незнакомцем / принцип наименьшего знания).

PoLA - компонент системы должен вести себя в соответствии с вероятными ожиданиями пользователей (принцип наименьшего удивления):

  • скрывай / инкапсулируй информацию;
  • используй константы вместо магических чисел;
  • проектируй на уровне интерфейсов, а не реализации;
  • данные обрабатывай в том классе, к которому они относятся.