Код необходимо разбить на компоненты, минимальная единица переиспользования - это класс.
Любое переиспользование влечет за собой более высокую связанность (coupling, есть еще вариант зацепление). Если компонент уже сильно связан с другими, то это значительно ограничивает возможности по его переиспользованию. В общем и целом, чем выше связанность компонентов, тем сложнее поддерживать приложение.
@important-links:Важные ссылки
Критерии качества архитектуры ПО - критерии качества архитектуры ПО.
Архитектура ПО - Stable Dependencies Principle - принцип устойчивости зависимостей, очень важен для определения возможности переиспользования классов (компонентов). На основании оценки устойчивости можно принимать решения о том, насколько безопасно зависеть от такого класса.
Архитектура ПО - Stable Abstractions Principle - принцип устойчивых абстракций, говорит о том, что абстрактность компонента или класса должна быть пропорциональна его устойчивости. То есть, максимально абстрактные компоненты должны быть максимально устойчивыми, и наоборот. Соответственно, все остальные компоненты в пространстве “абстрактность-устойчивость” должны лежать недалеко от прямой, соединяющей эти два экстремума.
@practical-reuse:Как использовать это знание
Для использования этих принципов необходимо ответить на следующие вопросы:
- Что является “единицей кода” в вашем окружении? Каков минимальный уровень декомпозиции, позволяющий переиспользовать код? Для Java такими единицами являются классы и интерфейсы (и с некоторой натяжкой, публичные статичные методы, которых нужно избегать).
- Как единицы кода могут зависеть друг от друга? В Java это ссылочная зависимость (знание о существовании других классов) и отношения наследования.
- Как можно абстрагироваться от низкоуровневых деталей? В Java это можно сделать с помощью интерфейсов и абстрактных классов.
Зная ответы на эти вопросы, нужно следовать принципу устойчивых абстракций и избегать создания компонентов, которые были бы устойчивыми и очень конкретными, т.к. их изменение или переиспользование - это боль.
Если предполагается активное переиспользование какого-либо компонента, то нужно
очистить его от низкоуровневых деталей и свести его зависимости к минимуму (т.е.
превратить его в чистую абстракцию). Этого можно добиться путем создания
абстрактных методов и ссылок только на интерфейсы. Также помогает снижение числа
инструкций import и им подобных.
С другой стороны, если класс зависит от многих других, то его нельзя делать устойчивым, другими словами, нельзя переиспользовать.
Основной источник: Mental Maintainability Model