На этом шаге рассмотрим выбор операций при разработке интерфейса класса.
Разработка интерфейса класса или модуля — это трудная работа. Обычно сначала создается первое приближение класса, а затем, когда появляются клиенты класса, интерфейс расширяется, модифицируется и уточняется. В итоге, проектировщик может выявить шаблоны операций над данной абстракцией и создать новые классы или реорганизовать отношения между существующими классами.
Внутри класса принято хранить только элементарные операции, каждая из которых описывает небольшой, точно определенный аспект поведения. Такие методы называются мелкомодульными (fine-grained). Кроме того, целесообразно отделять друг от друга методы, не связанные между собой. Это намного облегчает создание подклассов, осуществляющих разумное переопределение поведения суперкласса. Выбор количества методов для описания поведения класса определяется двумя взаимно противоречивыми рассуждениями:
- Попытка описать поведение в одном методе упрощает интерфейс, но укрупняет и усложняет сам метод.
- Распределение функциональных возможностей между методами усложняет интерфейс, но упрощает методы.
В объектно-ориентированном проектировании принято рассматривать методы класса как единое целое, поскольку все они взаимодействуют друг с другом и образуют протокол абстракции. Таким образом, зная требуемое свойство системы, необходимо решить, в каком из классов его описать.
Хелберт (Helbert) и О'Брайен (O'Brian) предложили следующие критерии для принятия такого решения [Halbert, D., and O'Brien, P. September 1988. Using Types and Inheritance in Object-Oriented Programming. IEEE Software vol. 4(5), p. 74.]:
- Bозможность повторного использования: может ли данное свойство иметь смысл в другом контексте?
- Сложность: насколько трудно реализовать такое свойство?
- Применимость: насколько данное свойство характерно для класса, в который оно включается?
- Требования к реализации: зависит ли реализация данного свойства от внутренних деталей класса?
Как правило, операции над объектами объявляются в определении соответствующего класса (или суперкласса) в виде методов.
Выбрав конкретную операцию и определив ее функциональную семантику, проектировщик должен принять решение относительно ее временной и пространственной семантики. Это значит, что проектировщик должен определить время, которое потребуется для полного выполнения операции, а также объем памяти, необходимый для нее. Такие решения описываются с помощью наилучшего, среднего и худшего сценариев. При этом худшим считается сценарий, в котором для выполнения операции требуется наибольший объем ресурсов.
Объекты посылают сообщения друг другу по соединяющим их связям. Следовательно, связанные объекты должны быть каким-то образом синхронизированы. В параллельных системах управления механизм передачи сообщений намного сложнее, чем обычный вызов подпрограмм. В большинстве распространенных языков программирования синхронизация просто не нужна, поскольку все программы содержат только один поток управления, и все объекты действуют последовательно. В таких случаях передача сообщений называется простой, так как ее семантика больше похожа на простой вызов подпрограмм.
Однако в языках, поддерживающих параллельность, применяются более изощренные механизмы передачи сообщений. Это позволяет избежать проблем, возникающих, когда два потока одновременно воздействуют на один и тот же объект, никак не согласовывая свои операции. Объекты, семантика которых сохраняется в средах с несколькими потоками управления, называются защищенными (guarded), или синхронизированными (synchronized).
На следующем шаге рассмотрим выбор отношений между классами и объектами.
