Инкапсуляция
Наследование
Полиморфизм
Абстракция
Композиция
| Постулат | Что это? | Зачем это? |
|---|---|---|
| Инкапсуляция | Принцип сокрытия данных и методов от общего доступа | От предотвращение прямого изменение состояния. Сокрытие деталей реализации. Улучшение модульности. Повышение надежности. Легкость изменений и поддержки |
| Наследование | Форма отношений между классами позволяющий описать новый класс на основе уже существующего. | Повторное использование кода. Упрощение создания новых классов. Иерархическая структура(Определяет отношения между различными сущностями). Расширяемость. Полиморфизм(Абстрактные классы) |
| Полиморфизм | Способность программы использовать объекты с одинаковым интерфейсом без информации о конкретном типе объекта | Гибкость кода(Может использовать различные типы). Повторное использование кода. Упрощение структуры кода (избегая условные операторы). Поддержка расширяемости(Open/Close). Улучшение читаемости и поддержка кода |
| Абстракция | Общие характеристики объектов со скрытием сложных деталей | Упрощение сложных систем. Сокрытие деталей реализации и данным. Улучшение модульности. Поддержка расширяемости. Снижение дублирования кода. Повышение читаемости и поддержки кода |
| Композиция | Это принцип при котором классы создаются с использованием других объектов для реализации своей функциональности | Гибкость(путем комбинирования объектов). Повторное использование кода. Изоляция изменений(Заменена с аналогичным интерфейсом). Упрощение тестирования. Модульность |
| Постулат | Минусы |
|---|---|
| Инкапсуляция | Не даёт «черный ящик» с описанными входов и выходов. В чужих «чёрных ящиках» случаются ошибки. Программисты не доверяют чужим «черным ящикам» |
| Наследование | Дублирование кода в производных классах. Трудности с изменением поведения на стадии выполнения. Трудности в получением информации о всех аспектах поведения. Добавление нового поведения может не подходить |
| Полиморфизм | Не всегда полиморфизм легко реализовать на практике. Полиморфизм может ухудшать производительность кода. Связь полиморфизма с наследованием порой расценивают как слабое место всей концепции |
| Абстракция | Сложность проектирования. Потенциальная избыточность. Проблемы с производительностью. Сложности с пониманием. Неправильное использование. Изменение требований(Затрудняем адаптацию системы к новым условиям) |
| Композиция | Сложность в управлении зависимостями. Увеличение количества классов. Более сложное тестирование(зависимости друг от друга). Сложности в изменении интерфейсов. Проблемы с инициализацией |
Виды полиморфизма:
- Подтипный полиморфизм: Позволяет использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.
- Ad-hoc-полиморфизм: Перегрузка методов, приведение типов
- На уровне методов: Пре определение методов
- Параметрический полиморфизм: При котором функции или классы могут работать с любым типом данных. Достигается с помощью generics
Основные понятия Наследования:
- Базовый (родительский) класс: Содержит общие свойства и методы, которые могут быть использованы в производных классах.
- Производный (дочерний) класс: Это новый класс, который наследует свойства и методы базового класса.
2. Что такое статический метод. Где лучше использовать вызов статических методов, в каких патернах используются?
Это метод, который принадлежит классу, а не экземпляру объекта. Лучше всего использовать когда не требуется доступ к состоянию конкретного экземпляра класса.
Основные особенности статических методов:
- Они не могут обращаться к нестатическим свойствам или методам класса напрямую, только к другим статическим свойствам или методам.
- Они обычно используются для глобальных операций, общих для всех экземпляров класса, и не зависят от конкретного состояния объекта.
Factory Method, Singleton, Adapter
3. Что такое позднее статическое связывание как происходит как используется слово static и можно ли его переопределять
Это механизм в объектно-ориентированных языках программирования, который позволяет обрабатывать вызовы статических методов или свойств в контексте наследников. Да переопределять можно
DI (Dependency Injection) - это паттерн проектирования, который используется для управления зависимостями между объектами. Он позволяет внедрять зависимости в объекты извне, вместо того чтобы создавать их внутри объектов самостоятельно.
Преимущества использования DI в PHP:
- Упрощение тестирования: DI позволяет легко подменять зависимости объектов на моки или заглушки в тестах, что упрощает их изоляцию и проверку.
- Повышение переиспользуемости: Объекты становятся более независимыми и переиспользуемыми, поскольку их зависимости могут быть заменены без изменения самого объекта.
- Снижение связанности: Зависимости объявляются в явном виде, что уменьшает связанность между объектами. Это делает код более гибким и легко поддающимся изменениям.
- Читаемость и понятность: Когда зависимости передаются явно через конструктор или сеттеры, код становится более понятным и читаемым. Зависимости становятся явными, и легче понять, какие компоненты взаимодействуют между собой.
IoC - это широкий принцип проектирования, который определяет, что контроль над потоком выполнения программы должен быть передан внешнему компоненту или контейнеру. Вместо того чтобы объекты создавали и управляли своими зависимостями самостоятельно, они получают свои зависимости из внешнего источника. Таким образом, контроль над созданием и управлением объектов передается контейнеру или фреймворку, что позволяет легко внедрять зависимости в объекты.
DI - это конкретная реализация IoC, где зависимости передаются в объекты, обычно через конструкторы, сеттеры или методы-инъекторы. DI помогает обеспечить инверсию контроля и упрощает управление зависимостями между объектами.
Dependency Injection (внедрение зависимостей) - это техника, которая позволяет классу получать зависимости извне, вместо того, чтобы создавать их самому. Передаются через конструкторы, сеттеры или методы класса. Это делает классы более гибкими, модульными и тестируемыми, поскольку зависимости могут быть заменены или имитированы для тестирования или изменения поведения класса. DI помогает снизить связность и повысить переиспользуемость компонентов.
Dependency Inversion (инверсия зависимостей) - это принцип, предложенный в SOLID-принципах программирования, который гласит, что классы должны зависеть от абстракций, а не от конкретных реализаций. Это означает, что высокоуровневые модули не должны зависеть от низкоуровневых модулей, а оба типа модулей должны зависеть от абстракций.
Рефлексия (reflection) - это механизм, который позволяет программе анализировать и модифицировать свою структуру во время выполнения. Может быть полезен во многих случаях, таких как создание гибких фреймворков, анализ и изменение кода во время выполнения, реализация динамической интеграции
Композиция "Has-A Relationship" это отношение означает, что один объект является составной частью другого объекта и время жизни части зависит от времени жизни целого.
Агрегация "Part Of Relationship" если же один объект получает ссылку (указатель) на другой объект в процессе конструирования.
Композиция проще с точки зрения клиентов класса, но налагает определенные ограничения: "целое" должно уметь создавать "составную часть". Агрегация гибче, но налагает другие ограничения: теперь "целое" не скрывает о существовании "составной части", а значит и не сможет заменить ее на другую "составную часть" в будущем.
Заметка
Большое количество наследования говорит о том, что проектировщики забыли о старом добром совете Банды Четырех, который сводится к тому, что следует предпочесть агрегацию наследованию, поскольку первая дает большую гибкость и динамичность во время исполнения.Обилие же композиции говорит о нарушении Принципа Инверсии Зависимостей, сформулированном Бобом Мартином, которую сейчас можно выразить в терминах агрегации и композиции: предпочитайте агрегацию вместо композиции, поскольку первая стимулирует использование абстракций, а не конкретных классов.
- Авто загрузка
- HTTP интерфейсы (Response, Request)
- Интерфейсы (DI, Loger, Event dispatcher)
- Стилистика кода
Зацепление (coupling) описывает степень взаимосвязи и зависимости между компонентами системы. Чем выше зацепление, тем сильнее компоненты связаны друг с другом. Высокое зацепление может приводить к проблемам, таким как сложность изменений, трудности восприятия и повторного использования кода. Идеальным является слабое зацепление, когда компоненты системы имеют минимальную зависимость друг от друга.
Высокая связанность (cohesion) описывает степень, в которой элементы внутри компонента связаны и сфокусированы на одной задаче. Высокая связанность означает, что компонент выполняет свои функции без излишней зависимости от других компонентов. Высокая связанность способствует лучшей модульности, повышает понятность и повторное использование кода.
Важно стремиться к слабому зацеплению и высокой связанности при проектировании микросервисов, чтобы обеспечить легкость разработки, изменений и масштабируемости системы.