Интерфейс-маркер (Marker Interface) — это шаблон проектирования, в котором интерфейс служит просто как маркер, указывающий на какие-то особенности или возможности класса. В PHP интерфейсы-маркеры обычно не содержат методов, а используются лишь для определения принадлежности класса к определенной категории или для активации некоторого поведения. Примером может быть интерфейс Serializable, который является маркером для классов, которые могут …
Архивы рубрик:Паттерны
Паттерн «Репозиторий» (Repository pattern)
Паттерн «Репозиторий» (Repository pattern) представляет собой шаблон проектирования, который используется для абстрагирования слоя доступа к данным (DAL) от бизнес-логики приложения. Это позволяет изменять механизмы хранения данных без значительного влияния на код, который использует эти данные. В контексте PHP и разработки веб-приложений, использование паттерна репозиторий помогает достичь более чистой архитектуры, упрощает тестирование и поддержку кода. Пример …
Паттерн «Null Object» (или «Нулевой объект»)
Паттерн «Null Object» (или «Нулевой объект») — это поведенческий шаблон проектирования, который предлагает использовать специальный объект с нейтральным поведением вместо null. Этот паттерн помогает избежать многочисленных проверок на null в коде, делая его более читаемым и безопасным. Контекст использования Предположим, у нас есть веб-приложение на PHP, которое работает с системой логирования. В разных ситуациях система …
Паттерн «Особый случай» (Special Case Pattern)
Паттерн «Особый случай» (Special Case Pattern) в программировании представляет собой способ обработки особых случаев обращения к объекту, когда возвращается объект, который представляет отсутствие (или исключительное состояние) значения, вместо использования null. Этот паттерн часто используется для упрощения кода, избегая многочисленных проверок на null. Пример на PHP: Допустим, у нас есть система, в которой пользователи могут иметь …
Читать далее «Паттерн «Особый случай» (Special Case Pattern)»
SOLID принципы: DIP (Принцип инверсии зависимостей (The Dependency Inversion Principle)
Существует два определения. «Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.» и «Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.» Как соблюдать этот принцип. Вы должны использовать все классы через интерфейсы.
SOLID принципы: ISP (Принцип Разделения Интерфейса (The Interface Segregation Principle)
Клиента не должны зависеть от методов который они не используют. Т.е. если какой то метод интерфейса не используется клиентом, то изменения этого метода не должны приводить к необходимости внесения изменения в клиентский код. (Р. Мартин) Вывод: Много специальных интерфейсов, предназначенных для клиентов, лучше, чем один общий интерфейс
SOLID принцип: LSP Принцип подстановки Барбары Лисков (The Liskov Substitution Principle) объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.
Т.е. Если у вас есть место куда приходит класс (parent), то должна быть возможность без каких либо проблем добавляться и его наследник. Так же есть формулировка от Герба Саттера и Андрея Александреску: «Подкласс не должен требовать от вызывающего кода, больше чем базовый класс. И не должен предоставлять вызывающему коду, меньше чем базовый класс.»
SOLID принципы: OCP (Открытости/закрытости (Open Closed Principle)
Программные сущности (модули, классы, функции и т.д.) должны быть открыты для расширения, но закрыты для изменения (Бертранд Мэер) «Открыты для расширения», означает, что любой класс, метод, блок программного кода должен быть открыт для добавления нового функционала «Закрыты для изменения»: для добавления нового функционала в сущность, не должны вноситься изменения в код, который эту сущность использует. …
Читать далее «SOLID принципы: OCP (Открытости/закрытости (Open Closed Principle)»
SOLID принципы: SRP (Принцип единственной ответственности, Single Responsibility Principle)
Каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкассирована в класс (Робер Мартин). Через ваш класс должна проходить только одна ось изменений (Сергей Немчинский) Т.е. Ваш класс должен меняться только по одной причине (содержать поля и методы относящиеся к одному вопросу). Никаких Gob Object. Осмысленно используйте SRP. Не следует, необдуманно, рубить …