Одна из главных проблем в разработке программного обеспечения – борьба с возрастающей сложностью системы. Решением этой проблемы занимаются с времен появления первых программ. Результатами являются языки, всё более упрощающие взаимодействие с машиной, парадигмы программирования вроде ООП, паттерны. В этой статье будут рассмотрены принципы программирования, позволяющие уменьшить сложность и облегчить сопровождение системы.
1. Инкапсулируйте то, что изменяется.
Это основа всего ООП. Надо выделить компоненты, которые могут измениться, и отделить их от части системы, которая останется неизменной. Инкапсуляция позволит изменить или расширить выделенные компоненты без изменения остальной части системы. Основная проблема здесь в том, как лучше всего разделить приложение на части. Все паттерны проектирования занимаются ответом на этот вопрос.
2. Предпочитайте композицию наследованию.
При композиции поведение не наследуется, а предоставляется для использования правильно выбранным объектом. Так же композиция позволяет изменить поведение объекта, если он подключен не напрямую, а через интерфейс (см. след. принцип). Естественно, везде фанатично применять композицию и совсем отказаться от наследования было бы неразумно.
3. Код должен зависеть от абстракций, а не от конкретных реализаций.
Высокоуровневые компоненты не должны зависеть от низкоуровневых, и те и другие должны зависеть от абстракций. Авторы этой книги называют его принципом инверсии зависимостей (Inversion of Control, IoC). Лучше выделить контракт класса в интерфейс, а затем реализовать его. Например вместо:
private ArrayList<String> someMap = new ArrayList<String>();
надо писать:
private List<String> someMap = new ArrayList<String>();
Соответственно, в аксессорах, в вызовах методов должны использоваться абстракции, а не реализации. Теперь при необходимости изменить поведение списка на двусвязный достаточно поменять только одну строку:
private List<String> someMap = new LinkedList<String>();
4. Стремитесь к слабой связности взаимодействующих объектов.
Чем меньше объекты знают друг о друге, тем гибче система. Одному компоненту нет необходимости знать о внутреннем устройстве другого.
5. Классы должны быть открыты для расширения, но закрыты для изменения.
Это так называемый принцип «Открытости/закрытости». В разные периоды времени его реализовывали разным образом. Бертран Мейер предлагал в своей книге не изменять созданную реализацию класса, а при необходимости внесения изменений расширять класс посредством создания наследников. Позже была выдвинута идея использовать интерфейсы, реализации которых могут быть полиморфно заменены одна на другую при необходимости.
6. Взаимодействуйте только с близкими друзьями.
Это принцип минимальной информированности. При проектировании класса надо обращать внимание на количество классов, с которыми будет происходить его взаимодействие. Чем меньше таких классов, тем гибче система.
7. Не вызывайте нас – мы сами вас вызовем.
Или голливудский принцип. По Фаулеру – это синоним принципа IoC. Согласно идеи, компоненты высокого уровня (например, интерфейсы) определяют за компоненты низкого уровня (реализации), как и когда им подключаться к системе. Авторы Head First Design Patterns допускают, что согласно этому принципу компоненты низкого уровня могут участвовать в вычислениях без формирования зависимостей с компонентами высокого уровня, и в этом состоит отличие от более жесткого IoC.
8. Класс (или метод) должен иметь только одну причину для изменения.
Это так называемый «принцип одной обязанности». Чем больше причин для изменения, тем больше вероятность изменения. А изменение – причина массы проблем. Принцип указывает на то, что классу (как и методу) должна быть выделена только одна обязанность. Например, в хорошо спроектированной системе с трехслойной архитектурой: один метод DAO делает ровно один запрос в базу, один метод сервиса выполняет ровно одну задачу бизнес-логики, один метод контроллера вызывает сервис ровно один раз.
Практически все принципы пересекаются друг с другом, у всех задача одна и та же – уменьшение сложности системы и, как следствие, жизни программистов. Хочется верить, что чья-то жизнь станет легче после прочтения =)
Автор: mrmaxim
