На этом шаге рассмотрим выбор реализации класса.
Внутреннее представление класса или объекта разрабатывается только после завершения проектирования их внешнего представления. При этом необходимо принять два проектных решения: выбрать способ представления класса или объекта и определить способ их размещения в модуле.
Представление классов и объектов почти всегда должно быть инкапсулировано. Это позволяет вносить изменения (например, модифицировать способы использования памяти и временных ресурсов), не нарушая предположения о функциональных свойствах класса или объекта, которые могут иметь их клиенты. Выбор способа представления является нелегкой задачей и не определяется одними лишь доступными техническими средствами. Он всегда должен рассматриваться с точки зрения операций над данными [Wirth, N. 1986. Algorithms and Data Structures. Englewood Cliffs, NJ: Prentice-Hall, p. 37.].
Например, разрабатывая класс, объекты которого определяют планы полетов самолетов, необходимо решить, как оптимизировать его представление — ускорив поиск или ускорив операции вставки и удаления. Поскольку одновременно оптимизировать и то, и другое невозможно, выбор следует делать, исходя из будущего использования объектов. Иногда такой выбор сделать непросто, и проектировщик выбирает семейство классов с практически одинаковыми интерфейсами, но совершенно разными реализациями, стремясь обеспечить разные способы использования ресурсов.
Одним из наиболее трудных компромиссов является выбор между вычислением состояния объекта и хранением его в поле данных. Рассмотрим, например, класс Cone (Конус), содержащий метод Volume (Объем). Этот метод возвращает объем конуса.
Представление конуса, как правило, хранит высоту и радиус основания в полях данных. Следует ли создать дополнительное поле данных для объема или же вычислять его по мере необходимости с помощью метода Volume [Keene, S. 1989. Object-Oriented Programming in Common Lisp. Reading, MA: Addison-Wesley, p. 68.]? Если необходимо, чтобы объем конуса вычислялся быстро, то объем следует хранить в поле данных. Если экономия памяти важнее, то лучше вычислить это значение.
Оптимальный способ представления объекта всегда определяется спецификой решаемой задачи. В любом случае этот выбор не должен зависеть от внешнего представления класса.
Аналогичные вопросы возникают при распределении объявления классов и объектов по модулям. Решение обычно принимается путем компромисса между взаимно противоречивыми требованиями к видимости и сокрытию информации.
Как правило, модули должны быть функционально связными внутри и слабо связанными друг с другом. При этом необходимо учитывать многие нетехнические факторы, такие как возможность повторного использования, безопасность и документирование. Проектирование модулей не менее сложная задача, чем проектирование классов и объектов.
На следующем шаге рассмотрим базовые понятия класса в нотации UML.
