Архивы Архитектура - Уголок сельского джависта

Принцип разделения интерфейса — SOLID деталях

Четвёртый принцип SOLID — принцип разделения интерфейса (Interface Segregation Principle, ISP), и гласит он следующим образом: «Программные сущности не должны зависеть от методов, которые они не используют». Однако с течением времени данный принцип стал применим не только к интерфейсам, но и к другим аспектам разработки программного обеспечения, что отражено в книге Роберта Мартина «Читая Архитектура»: «Этот принцип призывает разработчиков программного обеспечения избегать зависимости от всего, что не используется». Предлагаю сначала разобраться с интерфейсами, а затем рассмотреть несколько примеров более широкого применения принципа.

Шаблонный метод — шаблоны проектирования в деталях

Шаблонный метод — это популярный поведенческий шаблон проектирования. При его помощи можно задать некоторое поведение в методе абстрактного класса, но при этом оставить детали реализации на классы-наследники. Проще говоря, в контексте языка программирования Java шаблонный метод — это метод абстрактного класса или метод по умолчанию интерфейса, задающий общее поведение, но опирающийся на другие абстрактные методы. Шаблонный метод наряду с шаблоном проектирования «Стратегия» часто применяется при реализации инверсии управления.

Инверсия управления

Одним из наиболее значимых принципов объектно-ориентированного программирования является инверсия управления или принцип инверсии управления. Так же этот принцип в шутку назван «Голливудским принципом», смысл которого раскрывается в определении: «Не звоните нам, мы сами вам позвоним». Данный принцип позволяет существенно снизить связанность между компонентами программного обеспечения, а также изменить процесс его разработки таким образом, чтобы сторонние фреймворки могли использовать компоненты, разрабатываемые другими разработчиками.

Внедрение и поиск зависимостей

Прежде чем браться за материалы, посвящённые Spring Framework, мне хотелось бы повторить тему инверсии управления, так как этот принцип и его реализации в виде внедрения и поиска зависимостей являются важной составляющей ядра Spring Framework.

Под инверсией управления понимается подход к написанию кода, при котором элементы кода получают поток управления неявно от некоторого фреймворка. Иными словами, если сравнивать с традиционным процедурным программированием, не код обращается к фреймворку или библиотекам для выполнения какого-либо действия, а наоборот, фреймворк обращается к нашему коду.

Шаблон проектирования адаптер

При написании материалов я так или иначе касаюсь темы шаблонов проектирования, однако я обратил своё внимание на то, что нередко путаюсь в их названиях. Поэтому я решил перечитать книгу «банды четырёх», а заодно написать цикл материалов по шаблонам проектирования с примерами кода на языке программирования Java.

Открывает цикл материалов статья о шаблоне проектирования «адаптер». Адаптер, так же известный как «обёртка» (wrapper), применяется в тех случаях, когда некоторый существующий класс необходимо адаптировать под использование с другим целевым интерфейсом без внесения изменений в адаптируемый класс, дабы не нарушать принцип открытости/закрытости.

SOLID в деталях: Принцип подстановки Лисков

Третьим принципом в списке SOLID является Принцип подстановки Лисков (Liskov Substitution Principle; LSP), который из всех принципов имеет самую сложную формулировку, звучащую следующим образом:

Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.
Барбара Лисков

SOLID в деталях: принцип открытости/закрытости

Принцип открытости/закрытости (Open-Closed Principle; OCP), на мой взгляд, является главным принципом в списке принципов SOLID, в то время как все остальные в той или иной мере обеспечивают его соблюдение. Этот принцип сформулировал Бертран Мейер в своей книге «Object-Oriented Software Construction» в 1988 году следующим образом: «Программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для изменения» (Software entities (classes, modules, functions, etc) should be open for extension, but closed for modification). Иными словами, должна иметься возможность изменять поведение программных сущностей без их изменения, как написал Роберт Мартин в книге «Чистая архитектура».

SOLID в деталях: Принцип единственной ответственности

Я уже писал ранее в своём блоге о принципах SOLID, но это было практически пять лет назад, с тех пор утекло немало воды, а я всё это время на ежедневной основе набирался опыта их применения в проектах разных масштабов от мала до велика. И, когда в очередной раз прочитал свои старые заметки, я понял, что опыт внёс определённые корректировки в понимание принципов SOLID, а это хороший повод снова по ним пройтись. Эта статья, а так же последующие предполагают, что мои ранее написанные заметки по принципам SOLID можно не брать в расчёт.

Идентификаторы для распределённых систем

Каждый объект в информационной системе имеет некоторый признак по которому его можно однозначно идентифицировать — идентификатор. Если речь идёт о простых системах, то там вполне достаточно целочисленных идентификаторов, генерируемых средствами СУБД, или UUID. Они просты в использовании и понимании, но в то же время их возможностей недостаточно при построении распределённых систем, либо их поддержка создаёт определённые сложности.

Ветвление кода без исключений

Использование исключений для управления потоком выполнения является достаточно распространённой практикой. Однако во многих статьях и книгах, посвящённым лучшим практикам, например в замечательной книге Джошуа Блоха “Java — Эффективное программирование“ (Effective Java, Joshua Bloch), даётся рекомендация не использовать исключения как способ ветвления кода.