Сколько всего принципов у дизайнерских шаблонов
Categories:
Раньше было всего 5 принципов, известных как SOLID:
Принцип единственной ответственности (Single Responsibility Principle, SRP): Класс должен иметь только одну причину для изменения, то есть класс должен нести только одну ответственность.Принцип открытости/закрытости (Open/Closed Principle, OCP): Программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации, то есть изменения должны достигаться за счет расширения, а не за счет изменения существующего кода.Принцип подстановки Лисков (Liskov Substitution Principle, LSP): Подтипы должны быть в состоянии заменять свои базовые типы, то есть производные классы должны быть в состоянии заменять свои базовые классы без влияния на корректность программы.Принцип разделения интерфейса (Interface Segregation Principle, ISP): Не следует заставлять клиента зависеть от интерфейсов, которые он не использует. Большие интерфейсы следует разбивать на более мелкие, более специфичные интерфейсы, чтобы клиенты знали только о методах, которые им нужно использовать.Принцип инверсии зависимостей (Dependency Inversion Principle, DIP): Высокоуровневые модули не должны зависеть от низкоуровневых модулей, оба должны зависеть от абстракций. Абстракции не должны зависеть от деталей реализации, а детали реализации должны зависеть от абстракций.
Позже добавили еще два правила, которые более конкретны и руководствуются ими. Мы можем видеть из объяснения принципа, что SOLID описывает что следует делать, а добавленные правила описывают что следует делать в первую очередь/лучше всего.
Принцип повторного использования композиции/агрегации (Composition/Aggregation Reuse Principle, CARP): При повторном использовании кода следует в первую очередь использовать композицию (композицию) и агрегацию объектов, а не наследование.Закон Деметры (Law of Demeter, LoD): Объект должен иметь как можно меньше знаний об других объектах, то есть объект должен как можно меньше знать о внутренней структуре и деталях реализации других объектов.
Помимо упомянутых выше общих принципов проектирования, существуют и другие принципы проектирования, которые, хотя и не так широко известны, как упомянутые выше, но также играют важную руководящую роль в проектировании программного обеспечения и архитектуре. Последующие правила, похоже, являются лишними, по крайней мере, я считаю, что они не противоречат интуиции и не требуют глубокого размышления.
Принцип минимальных знаний (Principle of Least Knowledge, PoLK): Также известен как расширение закона Деметры, утверждает, что объект должен как можно меньше знать о другой информации об объектах. Этот принцип был впервые предложен в 1987 году Патрицией Лаго (Patricia Lago) и Коосом Виссером (Koos Visser) в их работе “Принцип минимальной коммуникации”.Принцип стабильных зависимостей (Stable Dependencies Principle, SDP): Этот принцип считает, что проектирование программного обеспечения должно обеспечивать, чтобы стабильные компоненты не зависели от нестабильных компонентов, то есть компоненты с более высокой стабильностью должны меньше зависеть от компонентов с более низкой стабильностью. Эта идея принципа возникла в результате глубоких исследований отношений между компонентами программной системы.Принцип стабильной абстракции (Stable Abstraction Principle, SAP): В дополнение к принципу стабильных зависимостей, этот принцип направляет соответствие абстрактности и стабильности, то есть стабильные компоненты должны быть абстрактными, а нестабильные компоненты должны быть конкретными. Этот принцип помогает обеспечить стабильность и гибкость программной системы.