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