Здравствуйте, BlackEric, Вы писали:
BE>Вчера на собеседовании спросили что это такое. А я даже не слышал про это 
BE>Package principles
BE>Это дальнейшее развитие SOLID? Я правильно понимаю? Какего использовать и зачем оно нужно?
Достаточно часто возникает потребность группировки классов в подсистемы, пакеты и компоненты. Эта задача смыкается с задачей архитектурного проектированияи ориентирована на минимизацию сцепления пакетов и компонентов. Обсудим три принципа, способствующих ее решению.
Принцип эквивалентности повторного применения (REP — Release Reuse Equivalency Principle). Уровень детализации повторною применения (reuse) должен соответствовать желаемому уровню детализации новой версии. Речь идет об определении уровня повторного применения — ведь оно может обеспечиваться на уровне класса, группы классов, пакетов, компонентов, подсистем. Чем выше уровень, тем дороже обеспечивать возможность reuse, тем меньше универсальность модуля. В конце концов, все зависит от разработчиков новой версии (новой системы): из модулей какого размера они хотят собирать новый продукт? Размер повторно применяемого модуля определяет соглашение между текущими разработчиками и лицами, заинтересованными в повторном применении.
Принцип общего закрытия (ССР — Common Closure Principle). Классы, входящие в состав пакета, должны быть закрыты по отношению к одним и тем же изменениям. Изменение, влияющее на пакет, оказывает воздействие на асе классы этою пакета, не затрагивая другие пакеты. Классы как элементы пакета должны иметь между собой высокую связность. Иными словами, классы внутри пакета реализуют требования, ориентированные на одну и ту же функциональность. Когда требования к функциональности меняются, изменения затрагивают только содержимое пакета. Такая упаковка обеспечивает более эффективный контроль изменений и управление версиями.
Принцип общего повторного применения (CRP Common Reuse Principle). Кик сы, входящие в состав пакета, повторно применяются совместно. Если вы повторно применяете один из классов пакета, вы повторно применяете их все. Отсюда следует, что в составе пакета не должно быть лишних, посторонних классов (из-за которых от пакета может отказаться лицо, заинтересованное в повторном применении). Классы в пакете должны демонстрировать высокую взаимную связность. При изменении любого класса меняется версия пакета. Изменение версии пакета инициирует большой объем работы: тотальное обновление и тестирование всех зависимых пакетов. И это второй аргумент в пользу крайне осторожного включения классов в подобный пакет.
Выковырял из учебника для ВУЗа от Орлова
