вторник, 20 июля 2010 г.

ООП. Введение в хороший дизайн.

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

Признаки "плохого" дизайна:
  1. Закрепощенность: система с трудом поддается изменениям, поскольку любое изменение вызывает эффект "снежного кома", затрагивающего другие компоненты системы.
  2. Неустойчивость: в результате осуществляемых изменений система разрушается в тех местах, которые не имеют прямого отношения непосредственно к изменяемому компоненту.
  3. Неподвижность: достаточно трудно разделить систему на компоненты, которые могли бы повторно использоваться в других системах.
  4. Вязкость: сделать что-то правильно намного сложней, чем выполнить какие-либо некорректные действия.
  5. Неоправданная сложность: проект включает инфраструктуру, применении которой не влечет непосредственной выгоды.
  6. Неоправданные повторения: проект содержит повторяющиеся структуры, которые могут унифицироваться с применением простой абстракции.
  7. Неопределенность: проект трудно читать и понимать. Недостаточно четко выражено содержимое проекта.
Итак, принципы, позволяющие разработчикам исключить недостатки, свойственные "плохому" дизайну. Эти принципы собрал воедино Роберт Мартин, aka дядя Боб. Вот они, известные также под аббревиатурой S.O.L.I.D.:
  1. Принцип персональной ответственности (Single Responsibility Principle) – класс обладает только одной ответственностью, поэтому существует только одна причина, приводящая к его изменению.
  2. Принцип открытия-закрытия (Open-Closed Principle) – классы должны быть открыты для расширений, но закрыты для модификаций. Приветствует делегирование вместо изменения кода классов
  3. Принцип подстановки Лискоу (Liskov Substitution Principle) – дочерние классы можно использовать через интерфейсы базовых классов без знания о том, что это именно дочерний класс. Иначе – дочерний класс не должен отрицать поведение родительского класса и должна быть возможность использовать дочерний класс везде, где использовался родительский класс. Этот принцип не дает нам рождать высокие деревья наследования, указывая, где с наследованием уже пора заканчивать.
  4. Принцип отделения интерфейса (Interface Segregation Principle) – клиенты не должны попадать в зависимость от методов, которыми они не пользуются. Клиенты определяют, какие интерфейсы им нужны. Принцип призывает создавать небольшие и четкие интерфейсы, структуру которых диктуют клиенты.
  5. Принцип инверсии зависимостей (Dependency Inversion Principle) – зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не зависят от подробностей. Принцип призывает отказываться от статических зависимостей и строить архитектуру на основе интерфейсов, которые определяют, что именно модули нижних уровней должны уметь делать для того, чтобы верхние уровни были довольны.
На мой взгляд хорошая презентация, объясняющая принципы ООП.

Если первые четыре принципа можно соблюдать на ментальном уровне, то последний требует еще и некой инфраструктуры. Т.к. во время выполнения, за всеми этими абстракциями должны появиться реальные объекты, реализующие эти интерфейсы.


В своей статье, "Inversion of Control Containers and the Dependency Injection pattern" Мартин Фаулер пытаеться объяснить этот принцип, переводом которой я и занялся.

Ссылки по теме.
Слайдкаст по принципам проектирования
Доклад с конференции AgileDays-2009. ОО дизайн: SOLID принципы
Управление зависимостями в PHP-коде

Using a Dependency Injection Container with Zend_Application

Комментариев нет:

Отправить комментарий