Основы объектно-ориентированного проектирования

         

Метод получения классов


Мало-помалу идеи, обсуждаемые в этой лекции, в совокупности дают то, что не слишком претенциозно можно называть методом получения классов при конструировании ПО (напомним, метод - это способ породить, воспитать, проложить дорогу, создать нечто стоящее).

Идентификация класса требует двух неразрывно связанных видов деятельности - выявления множества кандидатов в классы и отбора среди них действительно нужных. В двух следующих таблицах подводятся итоги.

Прежде всего начнем с источников классов.

Таблица 4.1. Источники возможных классовИсточник идейЧто ищется
Существующие библиотеки
  • Классы, отвечающие потребностям приложения.
  • Классы, описывающие концепции, релевантные приложению.
Документ требований
  • Часто встречающиеся термины.
  • Термины, заданные явными определениями.
  • Термины, не определенные точно, но считающиеся само собой разумеющимися.
  • (Грамматические категории следует игнорировать.)
Обсуждения с заказчиками и будущими пользователями
  • Важные абстракции проблемной области.
  • Специфический жаргон проблемной области.
  • Помнить, что классы, приходящие из "внешнего мира", могут описывать как материальные, так и концептуальные объекты.
Документация (руководства пользователей) для других систем в той же проблемной области, например от конкурентов
  • Важные абстракции проблемной области.
  • Специфический жаргон проблемной области.
  • Полезные абстракции проектирования.
Не ОО-системы и их описания
  • Элементы данных, передаваемые в виде аргументов компонентам ПО.
  • Разделяемые данные (Common блоки FORTRAN).
  • Важные файлы.
  • Секции данных (COBOL).
  • Типы записей (Pascal, C, C++).
  • Сущности при ER-моделировании.
Обсуждения с опытными проектировщиками
  • Классы проектирования, успешно используемые в предыдущих разработках.
Литература по алгоритмам и структурам данных
  • Известные структуры данных, поддержанные эффективными алгоритмами.
Литература по ОО-проектированию
  • Применимые образцы проектирования.

Рассмотрим теперь критерии, позволяющие более внимательно исследовать классы и, возможно, отвергнуть часть из них.

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


Содержание раздела