Инкапсулируйте все, что может изменяться;
Уделяйте больше внимания интерфейсам, а не их реализациям;
Каждый класс в вашем приложении должен иметь только одно назначение;
Классы — это их поведение и функциональность.
Абстракция — отделение концепции от ее экземпляра;
Полиморфизм — реализация задач одной и той же идеи разными способами;
Наследование — способность объекта или класса базироваться на другом объекте или классе. Это главный механизм для повторного использования кода. Наследственное отношение классов четко определяет их иерархию;
Инкапсуляция — размещение одного объекта или класса внутри другого для разграничения доступа к ним.
Делегация — перепоручение задачи от внешнего объекта внутреннему;
Композиция — включение объектом-контейнером объекта-содержимого и управление его поведением; последний не может существовать вне первого;
Агрегация — включение объектом-контейнером ссылки на объект-содержимое; при уничтожении первого последний продолжает существование.
Избегайте повторного написания кода, вынося в абстракции часто используемые задачи и данные. Каждая часть вашего кода или информации должна находиться в единственном числе в единственном доступном месте. Это один из принципов читаемого кода.
SOLID
Резюмируя всё выше изложенное, хотелось бы сделать следующую шпаргалку
Принцип единственной ответственности (Single responsibility)
«На каждый объект должна быть возложена одна единственная обязанность»
Для этого проверяем, сколько у нас есть причин для изменения класса — если больше одной, то следует разбить данный класс.
Принцип открытости/закрытости (Open-closed)
«Программные сущности должны быть открыты для расширения, но закрыты для модификации»
Для этого представляем наш класс как «чёрный ящик» и смотрим, можем ли в таком случае изменить его поведение.
Принцип подстановки Барбары Лисков (Liskov substitution)
«Объекты в программе могут быть заменены их наследниками без изменения свойств программы»
Для этого проверяем, не усилили ли мы предусловия и не ослабили ли постусловия. Если это произошло — то принцип не соблюдается
Принцип разделения интерфейса (Interface segregation)
«Много специализированных интерфейсов лучше, чем один универсальный»
Проверяем, насколько много интерфейс содержит методов и насколько разные функции накладываются на эти методы, и если необходимо — разбиваем интерфейсы.
Принцип инверсии зависимостей (Dependency Invertion)
«Зависимости должны строится относительно абстракций, а не деталей»
Проверяем, зависят ли классы от каких-то других классов(непосредственно инстанцируют объекты других классов и т.д) и если эта зависимость имеет место, заменяем на зависимость от абстракции.
у тебя есть наследование/композиция/агрегация, вот придумай как комбинировать, чтобы не дублировать логику и получился нормальный код, ты же можешь по смыслу схожие типы взять под общий интерфейс, например, или унаследоваться, но все зависит от того как будет дальше это развиваться
Методы которые отображают
Методы которые изменяют
Связанность и связность
Закон Деметры
Делай максимальный isolation level, суй везде FK, заворачивай каждый чих в транзакцию и будет тебе полный acid
Нормальная декомпозиция служит всего 1 цели - пониманию, мы нарезаем задачу чтобы понять что у нее внутри
Фабрики Factory Добавить Изменить Удалить Ветка SimpleFactory (простая фабрика) - обертка для классов позволяет решить проблему дублирования и изменения кода путем оборачивания в класс выше с аргументами (вызывается как статический метод)
***Factory.php
AbstractFactor - объекдиняет объекты одних типов и в дальнейшем работает с ними.
Фабрики - берут сырые данные и преобразуют их в объект (например из файла)
Закрыть
DI это один из способов управлять композицией. По сути DI это то, как мы получаем объекты одних классов внутри других. А композиция - это совокупность классов на замену наследованию. Другими словами это как "колесо" и "крутиться" - не одно и то же)
То есть композицию из классов можно составить и без DI - просто создавая объекты внутри при помощи new
Термины foobar, foo, bar и baz часто используются как метапеременные в программировании или документации. В основном они означают неизвестные переменные, обычно в случаях, когда их цель известна, а значение не важно. Их используют в качестве названий переменных, функций, команд и т.д.