- •3 Системное программное обеспечение.
- •Инструментарий технологии программирования.
- •Пакеты прикладных программ.
- •Суть поиска подходящих объектов при проектировании.
- •Специфицирование интерфейсов объекта.
- •Специфицирование реализации объектов.
- •Механизмы повторного использования.
- •Сравнение структур времени выполнения и времени компиляции.
- •Проектирование с учетом будущих изменений
- •Прикладные программы. Инструментальные библиотеки. Каркасы приложений.
- •Признаки плохого проекта.
- •Принцип персональной ответственности
- •15. Принцип открытия – закрытия (оср)
- •17. Принцип инверсии зависимостей.
- •Обратное влияние клиентов на интерфейсы
Обратное влияние клиентов на интерфейсы
Когда речь идет о воздействиях, вызывающих изменения в программах, обычно это относится к тому, каким образом изменения в интерфейсах влияют на пользователей. Иногда пользователь вносит изменения в интерфейс. Например, некоторые пользователи Timer регистрируют более одного запроса за единицу времени. Рассмотрим объект TimedDoor. Если проверка показала, что объект Door открыт, объекту Timer направляется сообщение Register, содержащее запрос о перерыве. Но еще до окончания перерыва дверь закрывается, остается некоторое время закрытой, потом открывается снова. Вследствие этого регистрируется новый запрос об интервале еще до завершения первого интервала. Наконец, завершается первый интервал, вызывается функция Timeout из TimedDoor. Звуковой сигнал Door подается ошибочно. Можно исправить эту ситуацию с помощью соглашения
Timer with ID class Timer {
public:
void Register(int timeout,int timeOutld, TimerClient* client);};
class TimerClient {public:
virtual void TimeOut (int timeOutld =0;};
Ясно, что это изменение окажет влияние на всех пользователей TimerClient. Это происходит вследствие недостатков, присущих timeOutld.
ISP: принцип отделения интерфейса Когда клиенты вынужденно зависят от методов, которыми не пользуются, они становятся субъектами тех изменений, которым подвержены эти методы. В результате между всеми клиентами могут возникать непредсказуемые состыковки. Другими словами, если клиент находится в зависимости от класса, содержащего неиспользуемые данным клиентом методы, которые применяются другими клиентами, то клиент находится под влиянием изменений, вносимых в класс этими клиентами. Желательно избегать подобных состыковок, поэтому необходимо отделить интерфейсы.
Группировка клиентов Часто клиенты группируются вместе в соответствии со служебными методами, к которым они обращаются. Подобная группировка позволяет создавать выделенные интерфейсы для каждой группы, а не для каждого клиента. При этом подходе значительно сокращается количество интерфейсов, реализуемых данной службой, причем в данном случае служба не должна зависеть от каждого типа клиента. Иногда методы, вызываемые различными группами клиентов, "накладываются" друг на друга. Если "наложение" невелико, тогда интерфейсы этих групп остаются отделенными. Общие функции объявляются во всех частично совпадающих интерфейсах. Серверный класс наследует общие функции из каждого из этих интерфейсов, но реализует их только один раз. При поддержке объектно-ориентированных приложений часто изменяются интерфейсы существующих классов и компонентов. Иногда эти изменения имеют большое влияние и приводят к повторному компилированию и развертыванию очень больших частей системы. Эти процессы можно упростить, добавляя к существующим объектам новые интерфейсы без изменения существующего интерфейса. Клиенты "старых" интерфейсов, которым необходим доступ к новому интерфейсу, могут запрашивать объект для этого интерфейса, как показано в листинге/
void Client(Service* s) {
if (NewService* ns - dynamic_cast<NewService*>(s))
{// применение нового служебного интерфейса}
В соответствии с изложенными принципами, заботу следует проявлять, не слишком усердствуя при этом. Спектр класса с сотнями различных интерфейсов, некоторые из которых отделены от клиента, а другие — отделены от версии, может приобрести просто устрашающий вид.