Преимущества согласованного именования
Схема имен, данная выше, вносит наиболее видимый вклад в характерный стиль конструирования ПО, разрабатываемый в соответствии с принципами этой книги.
Не зашли ли мы слишком далеко в борьбе за согласованность? Не получится ли, что в программах будут использоваться одни и те же имена, но с разной семантикой? Например, item для стека возвращает элемент вершины, а для массива - элемент с заданным индексом.
При систематическом подходе к ОО-конструированию, использованию статической типизации и Проектированию по Контракту этот страх не оправдан. Знакомясь с компонентом, автор клиента может полагаться на четыре вида свойств, представленных в краткой форме класса:
- F1 Его имя.
- F2 Его сигнатура (число и типы аргументов, если это процедура, тип результата для запросов).
- F3 Предусловие и постусловие, если они заданы.
- F4 Заголовочный комментарий.
|
Подпрограммы имеют, конечно же, тело, но предполагается, что тело не должно волновать клиента. |
Три из этих элементов будут отличаться для вариантов базисных операций. Например, в краткой форме класса STACK можно найти компонент:
put (x: G) -- Втолкнуть x на вершину require writable: not full ensure not_empty: not empty pushed: item = xВ классе ARRAY появляется однофамилец:
put (x: G; i: INTEGER) -- Заменить на x значение элемента с индексом i require not_too_small: i >= lower not_too_large: i <= upper ensure replaced: item (i) = xСигнатуры различаются, предусловия, постусловия, заголовочные комментарии - все различно. Использование имени put, не создавая путаницы, обращает внимание читателя на общую роль этих процедур: они обе обеспечивают базисный механизм изменений.
Эта согласованность оказывается одним из наиболее привлекательных аспектов метода, в частности библиотек. Новые пользователи быстро привыкают к ней и при появлении нового класса, следующего стандартному стилю, принимают его как старого знакомого и могут сразу же сосредоточиться на нужных им компонентах.
