За прошедшие годы стало ясно, что ни один стиль программирования не имеет монополии на такие фундаментальные и важные моменты, как соответствие требованиям, эффективность и производительность, удобство разработки и надежность системы. Нам довелось видеть множество восторгов, преувеличенных ожиданий, модных тенденций, горячего энтузиазма — всего этого в свое время было вдоволь и в отношении объектно-ориентированных технологий. Нельзя сказать, что данная технология не помогает решать определенные проблемы, но это не панацея, как думают многие.
Возьмем, к примеру, принцип объектной декомпозиции, используемый при разработке объектных иерархий. При тщательном моделировании объектов реального мира получаются удобные и понятные программные компоненты, из которых легко собираются даже крупномасштабные системы. Звучит многообещающе, не правда ли? Однако существует множество способов декомпозиции объектов реального мира, и эти объекты редко удается представить в виде простой иерархии. Например, декомпозицию нашего библиотечного каталога можно выполнить на основе, скажем, носителей (печатные материалы, аудиозаписи, цифровой формат и т. д.). Хотя Oracle предоставляет прекрасные возможности для эволюции типов, серьезные изменения в иерархии типов ведут к таким тяжелым последствиям, что на них обычно никто не решается. И не программные средства тому виной. Нельзя сказать, что объединение программной логики (методов) и данных (атрибутов) дает какие-либо очевидные преимущества. Пока никто еще убедительно не доказал, что это лучше, чем хранение структур данных (логической и физической структуры таблиц) отдельно от процессов (процедур, функций и пакетов). И многие признают, что структуры данных реальных компаний меняются гораздо реже, чем алгоритмы работы с этими данными. Даже среди проектировщиков ООП-систем общепризнанным является тот факт, что изменяющиеся элементы системы следует отделять от более стабильных. Последнее обстоятельство особенно интересно. Ярые приверженцы объектного подхода, которые настаивают на объединении данных и операций, в то же время подчеркивают важность подхода «модель-представление-контроллер», «отделяющего бизнес-логику от данных». Вам не кажется, что в этом есть некое противоречие?
Многие сторонники ООП главным преимуществом данного подхода считают возможность многократного использования кода. Это говорилось столько раз, что должно было уже стать правдой! К сожалению, мало кто потрудился привести убедительные доказательства, так как не существует четко определенного понятия «многократного использования». Даже приверженцы объектного подхода признают многократное использование возможным в первую очередь для компонентов высших уровней, поскольку объекты обычно предназначаются для узкоспециализированного применения. Наш опыт показывает, что возможность повторного использования объектного кода ничуть не выше, чем у обычных хорошо спроектированных программ.
Безусловно, объектно-ориентированные методы можно применять в PL/SQL для повторного использования программного кода. Наш соавтор Дон Бейлз (Don Bales), известный специалист по объектно-ориентированному программированию, использовал пакеты PL/SQL как «типы» около 10 лет, и он говорит, что ему удавалось брать целые пакеты (и сопровождающие таблицы) и переносить их в новые проекты без каких-либо изменений. Он считает, что «недостающим звеном» большинства объектных методов является точная модель человека, работающего с программным продуктом, — то есть пользователя. Дон моделирует его как объект с поведением, реализованным в выполняемой программе.
Независимо от выбора методологии разработки, среди ключевых факторов успеха программного продукта следует выделить опыт решения аналогичных задач, возможность привлечения опытных руководителей проектов, а также включение осмысленной фазы проектирования. Использование объектных или любых других методологий скорее приведет к положительному результату, чем неспланированная, хаотично разрастающаяся система.
В завершение приведем несколько рекомендаций, касающихся применения объектных функций Oracle:
- Если вы используете OCI (Oracle Call Interface), то возможность кэширования на стороне клиента и сложной выборки объектов могут склонить вас к интенсивному использованию объектных средств Oracle. Автор не работает с OCI и не может поделиться опытом в этой области.
- Если в вашей организации уже используется объектно-ориентированное программирование, объектные средства Oracle могут облегчить интеграцию технологий баз данных в имеющиеся системы.
- Даже если вы не намерены пользоваться объектным подходом, не отвергайте вместе с ним и коллекции. Помните, что они обладают широчайшими возможностями, а для их применения не нужны ни объектные типы, ни объектные представления.
- Тем, кто никогда не имел дела с объектно-ориентированным программированием, новые объектные возможности Oracle могут показаться сложными, однако время, потраченное на их освоение, не пройдет даром. В частности, попробуйте использовать объектные представления для существующих систем.
- Не стоит отвергать объектные типы и представления из-за неясных впечатлений об их низкой производительности. Oracle постоянно работает над ее повышением. Кроме того, тестирование может показать, что ООП вполне удовлетворяет требованиям приложения.
- Объектно-ориентированные типы используются и в некоторых встроенных средствах Oracle, напрямую не связанных с объектно-ориентированным программированием (прежде всего
XML_TYPE
, а также Advanced Queuing, Oracle Spatial и Rules Manager). Как неоднократно случалось в прошлом, после того как Oracle начинает пользоваться своей собственной функциональностью, ошибки начинают исправляться быстрее, производительность растет, а рабочие средства становятся более удобными. Так случилось и с объектными типами. Впрочем, важнее другое — для использования этих возможностей нужно иметь хотя бы общее представление об объектных типах, даже если вы сами создавать их не собираетесь.