На этом шаге рассмотрим основные механизмы и их идентификацию.
Термин механизм (mechanism) используется для описания любой структуры, в которой объекты взаимодействуют друг с другом для обеспечения поведения, удовлетворяющего требованиям задачи. Проект класса содержит априорные знания о поведении объектов, а механизм — это проектное решение, касающееся способа взаимодействия между совокупностью объектов.
Рассмотрим системное требование, предъявляемое к автомобилю: нажатие на педаль акселератора должно приводить к увеличению оборотов двигателя, а отпускание этой педали — к их уменьшению. Как это происходит на самом деле, водителю совершенно безразлично. В автомобиле может быть использован любой механизм, обеспечивающий требуемое поведение, и поэтому выбор его реализации предоставляется на усмотрение разработчика. Например, можно принять любое из перечисленных ниже проектных решений:
- Прямая механическая связь между акселератором и карбюратором.
- Электронный механизм, соединяющий датчик давления, расположенный под акселератором, с компьютером, управляющим топливным инжектором (проводной механизм).
- Отсутствие связей. Бак с горючим размещается на крыше автомобиля и топливо течет в двигатель под влиянием силы тяжести. Поток топлива регулируется зажимом на бензопроводе. Нажатие на педаль акселератора ослабляет зажим и ускоряет течение топлива (очень дешевый механизм).
Выбор альтернативных механизмов зависит от таких параметров, как стоимость, надежность, технологичность и безопасность. Выход объектов за пределы правил и ограничений, заданных конкретным механизмом, неприемлем точно так же, как нарушение правил взаимодействия между объектами. Водитель был бы удивлен, если бы, нажав на педаль акселератора, он включил фары, а не увеличил обороты двигателя.
В то время как основные абстракции отражают словарь проблемной области, механизмы определяют дух проекта. В процессе проектирования разработчик должен придумать не только представление классов, но и способы взаимодействия между их объектами. Здесь на помощь проектировщику вновь приходит анализ сценариев. Выбрав конкретный шаблон взаимодействия, проектировщик должен распределить работу среди многих объектов, обозначив подходящие методы. В итоге протокол отдельного класса описывает все операции, реализующие все его поведение и все механизмы, связанные с каждым из его экземпляров.
Таким образом, механизмы представляют собой стратегические проектные решения, аналогичные выбору структуры классов. В противоположность этому, проектирование интерфейса отдельного класса носит тактический характер.
Стратегические решения должны быть сделаны явно, иначе проект станет сборищем изолированных объектов, конфликтующих друг с другом и выполняющих свое задание без оглядки на других. В наиболее элегантных, стройных и быстрых программах воплощены тщательно продуманные механизмы.
Механизмы представляют собой разновидность шаблонов, существующих в структурированных системах. На нижнем конце этой цепочки находятся идиомы — выражения, присущие конкретным языкам программирования или предметным областям и отражающие общепринятые способы использования языка.
Например, в языке CLOS не принято использовать подчеркивание в именах функций или переменных, как в языке Ada [Gabriel, R. 1990. Private communication.]. Изучение идиом — неотъемлемая часть овладения языком. Как правило, они передаются от программиста к программисту в форме фольклора. Однако, как отметил Коплиен (Coplien), идиомы играют важную роль в систематизации шаблонов низкого уровня. Он заметил, что многие действия программистов являются идиоматическими и поэтому идентификация таких идиом позволяет использовать конструкции языка C++ для выражения функциональности, выходящей за рамки самого языка, с сохранением иллюзии, что они являются частью языка [Coplien, J. 1992. Advanced C++ Programming Styles and Idioms. Reading, MA: Addison-Wesley.].В то время как идиомы являются частью программистской культуры, на верху цепочки расположены среды разработки (framework) — совокупности классов, предназначенных для определенной прикладной ситуации. Таким образом, среда разработки поставляет готовые классы, механизмы и услуги, которые клиент может использовать или адаптировать. Среды разработки в основном обеспечивают возможность повторного использования классов. Часто они являются коммерческими продуктами, как, например, среда .NET компании Microsoft, или открытыми проектами, как среда Apache Software Foundation's Struts и Junit (авторы — Эрих Гамма (Erich Gamma) и Кент Бэк (Kent Beck)).
Рассмотрим в качестве примера механизм рисования, широко используемый в графических интерфейсах пользователя. Для того чтобы представить графический элемент на экране, необходимо взаимодействие нескольких объектов: окно, представление, представляемая модель и клиент, который знает, когда надо вывести эту модель на экран, но не имеет понятия, как это сделать. Сначала клиент просит окно нарисовать себя. Так как окно может иметь несколько представлений, оно в свою очередь приказывает каждому из них нарисовать себя. Каждое представление посылает сообщение своей модели нарисовать себя, в результате чего и появляется изображение на экране. В этом механизме модель полностью отделена от окна и своего представления в соответствии с парадигмой "модель-представление-контроллер" (model-view-controller — MVC) [Adams, S. July 1986. MetaMethods: The MVC Paradigm, hi HOOPLA: Hooray for Object-Oriented Programming Languages. Everette, WA: Object-Oriented Programming for Smalltalk Applications Developers Association vol. 1(4), p. 6.].
Таким образом, механизмы обеспечивают более высокий уровень повторного использования кода по сравнению с повторным использованием отдельных классов. Например, парадигма MVC широко используется в пользовательском интерфейсе языка Smalltalk. Эта парадигма, в свою очередь, строится на основе механизма зависимостей (dependency mechanism), встроенного в поведение базового класса Model языка Smalltalk и пронизывающего большую часть библиотеки классов языка Smalltalk.
Примеры механизмов и шаблонов можно найти практически во всех предметных областях. Например, структуру операционной системы можно описать на высоком уровне абстракции с помощью механизмов диспетчеризации программ.
В системах искусственного интеллекта используются разнообразные механизмы систем, реализующих механизм рассуждений (reasoning systems). Одной из наиболее распространенных парадигм является механизм "доски объявлений" (blackboard mechanism), которую каждый индивидуальный источник знаний заполняет независимо от других. В таком механизме не существует центрального управления, но любое изменение "доски объявлений" может явиться стимулом для поиска нового способа решения поставленной задачи [Englemore, R., and Morgan, T. 1988. Blackboard Systems. Wokingham, England: Addison-Wesley, p. v.]. Коад (Coad) похожим образом идентифицировал ряд общих механизмов в объектно-ориентированных системах, включая шаблоны временных ассоциаций (patterns of time associations), регистрацию событий (event logging) и широкую рассылку сообщений (broadcasting) [Coad, P. September 1992. Object-Oriented Patterns. Communications of the ACM vol. 35(9).]. Во всех перечисленных вариантах эти механизмы проявляются не как индивидуальные классы, а как структуры взаимодействующих классов.
На следующем шаге рассмотрим общие механизмы языка UML.
