Метод получения классов
Мало-помалу идеи, обсуждаемые в этой лекции, в совокупности дают то, что не слишком претенциозно можно называть методом получения классов при конструировании ПО (напомним, метод - это способ породить, воспитать, проложить дорогу, создать нечто стоящее).
Идентификация класса требует двух неразрывно связанных видов деятельности - выявления множества кандидатов в классы и отбора среди них действительно нужных. В двух следующих таблицах подводятся итоги.
Прежде всего начнем с источников классов.
Существующие библиотеки |
|
Документ требований |
|
Обсуждения с заказчиками и будущими пользователями |
|
Документация (руководства пользователей) для других систем в той же проблемной области, например от конкурентов |
|
Не ОО-системы и их описания |
|
Обсуждения с опытными проектировщиками |
|
Литература по алгоритмам и структурам данных |
|
Литература по ОО-проектированию |
|
Рассмотрим теперь критерии, позволяющие более внимательно исследовать классы и, возможно, отвергнуть часть из них.
Класс с вербальным именем (инфинитив или императив) | Может быть простой подпрограммой, а не классом |
Полностью эффективный класс с одной экспортируемой подпрограммой | Может быть простой подпрограммой, а не классом. |
Класс, описанный как "выполняющий нечто" | Может не быть подходящей абстракцией. |
Класс без подпрограмм | Может быть важной частью информации, но не АТД. Может быть АТД, для которого просто забыли указать операции. |
Класс, введенный без компонентов или с небольшим их числом (но наследующий компоненты своих родителей) | Может быть результатом "таксомании". |
Класс, покрывающий несколько абстракций | Должен быть разделен на несколько классов, по одному на каждую абстракцию. |