 |
Клиенты не должны иметь зависимость от интерфейсов, которые они не используют.
|
|
|
|
Суть данного принципа довольно проста. Если вы имеете класс, который состоит их нескольких клиентов, прежде чем записывать в класс все методы необходимые клиентам, создайте определенный интерфейс для каждого клиента, который будет являться наследником от этого класса.
18. 
19. Рисунок 7.7 Проблема сервис – многоженство клиентов
Лучшая техника представлена на рисунке ниже. Необходимые каждому клиенту методы находятся в специальных интерфейсах и определены для каждого клиента (т.е каждому клиенту соответствует свой отдельный интерфейс). Если интерфейс Client A нуждается в изменениях, Clients A и B остаются незатронутыми и их не потребуется заново компилировать и перезагружать.
Клиентов следует распределить на категории по их типу и для каждого типа следует создать отдельный интерфейс. Если два и более клиента разных типов используют одинаковый метод, то метод следует добавить в оба их интерфейса. Это не принесет ни вреда и не приведет к путанице.
20. Рисунок 7.8 Решение проблемы в соответствии с ISP
Интерфейсы существующих классов и компонентов часто приходится менять. В некоторых случаях такие изменения могут оказывать влияние на довольно большую часть проекта, что приведет к необходимости повторной компиляции и перезагрузке проекта. Избежать таких моментов возможно при добавлении новых интерфейсов к существующим объектам, вместо того чтобы вносить изменения в существующий интерфейс. Клиенты старого интерфейса, которые желают получить доступ к методам нового интерфейса могут сделать запрос. Код запроса приведен ниже:
void Client(Service* s) {
if (NewService*ns = dynamic_cast<NewService*>(s)) {
// use the new service interface
}
} Данный принцип подходит не ко всем случаям, поэтому прежде чем применять данный принцип, следует все тщательно взвесить и обдумать. Например, в случае, когда спектр класса довольно широк и имеет сотни различных интерфейсов использовать данный принцип было бы нецелесообразно, потому как программа стала бы еще более громоздкой и трудно читаемой.
|
|
|
Принципы проектирования
Конечно, классы необходимы, но недостаточны для организации хорошего проекта. Использование пакетов облегчает задачу организации качественного проекта. Но как нам выбрать какие классы должны принадлежать тому или иному пакету?
Гранула повторного использования есть гранула релиза – The Release-Reuse Equivalency Principle (REP)
Данный принцип помогает определить оптимальный размер пакета классов. Пакеты применяются для упорядочения набора классов. Обычно размер пакета в прикладной программе выбирается таким образом, чтобы соответствовать некоторому модулю релиза – разрабатываемому одним программистом за небольшой промежуток времени (до 5 дней).
Принцип говорит, что такие пакеты должны являться гранулами повторного использования. Т.е используя пакет, мы фактически используем все входящие в него классы. Поэтому следует избегать больших пакетов: «лишние» классы в лучшем случае являются ненужным балластом, а в худшем, могут помещать приложению. Нормальный размер пакета – от 1 до 8 классов.
Общий принцип повторного использования – The Common Reuse Principle (CRP). Классы, которые не используются повторно вместе, не следует объединят в один пакет.
Классы, объединенные в пакет - повторно используются вместе. Если вы повторно используете один из классов пакета, вы повторно используете все классы т.е создается зависимость на весь пакет. Этот принцип помогает нам решить, какие классы должны быть помещены в пакет, а какие нет. Классы, которые имеют тенденцию повторно использоваться вместе, должны принадлежать одному пакету.
Классы редко используются изолировано. В основном они связаны друг с другом. Простым примером может послужить контейнерный класс и его связь между его итераторами.
|
|
|
