77. Отличие объектно-ориентированного программирования от процедурного.

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

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

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

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

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

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

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

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

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