Изучаем Java

Завершим наше краткое введение в ООП анализом различий между ним и процедурной моделью.

В процедурно-ориентированном программировании сначала формулируется задача, а затем:

- с помощью пошагового уточнения исходная задача разбивается на все более мелкие подзадачи, пока они не станут настолько простыми, что их можно будет реализовать непосредственно (программирование "сверху вниз");

- создаются процедуры, предназначенные для решения простых задач;

- затем эти процедуры объединяются в более сложные, пока программа не станет делать именно то, что требуется (программирование "снизу вверх").

Большинство программистов, конечно, используют смешанные стратегии "сверху вниз" и "снизу вверх". При исследовании процедур нужно придерживаться такого же правила, как и при объектно-ориентированном программировании: ищите глаголы, или действия, в описании задачи. Существенное отличие заключается в том, что при объектно-ориентированном программировании в проекте сначала выделяются классы, и лишь затем определяются их методы. Между традиционными процедурами и ООП есть еще одна существенная разница: каждый метод связан с классом и класс отвечает за их выполнение.

Для решения небольших задач разбиение программы на процедуры вполне оправданно. Однако при разработке больших проектов классы и методы имеют два преимущества. Классы предоставляют удобный механизм кластеризации методов.

Простенький Web-броузер для своей реализации может потребовать 2000 функций и 100 классов, т.е. в среднем 20 методов в классе. Программисту намного легче понять именно последнюю структуру. Кроме того, ее легче распределить в команде программистов. Этому способствует также инкапсуляция: классы скрывают детали представления данных от любого кода, кроме своих методов. Как показано на рис. 4.2, это значит, что, если ошибка программирования искажает данные, причину легче найти среди 20 классов, чем среди 2000 процедур.

Рис. 4.2. Процедурное и объектно-ориентированное программирование

Можно возразить, что это не слишком отличается от принципа модульности (modularization). Наверняка, вам приходилось писать программы, разбивая их на модули, обменивающиеся друг с другом данными исключительно с помощью вызовов процедур, не прибегая к совместному использованию данных (sharing data). Если правильно пользоваться этим приемом, можно осуществить инкапсуляцию данных. Однако во многих языках программирования малейшее отклонение от этого подхода открывает доступ к данным из другого модуля — инкапсуляцию легко разрушить.

Есть более серьезная проблема: в то время как на основе класса можно создать несколько объектов с одинаковым поведением, в процедурно-ориентированных языках невозможно получить несколько копий одного модуля. Допустим, мы достигли модульной инкапсуляции, объединив совокупность заказов вместе с прекрасным сбалансированным бинарным деревом, обеспечивающим быстрый доступ. И вдруг выясняется, что нужно иметь две такие совокупности: одну для текущих заказов, а другую — для выполненных. Нельзя просто дважды вызвать модуль, реализующий дерево заказов. Для этого нужно скопировать и переименовать все процедуры! Классы не имеют таких ограничений.

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

Языку UML посвящено немало книг. Мы рекомендуем "Unified Modelling Landuage User Guide" by Grady Booch, IvarJacobson and James Rumbaugh (Addison-Wesley, 1999).