Три кита ООП (Объекто-ориентированное программирование)

Пролог

На заре компьютерной эры, когда польза от их использования обусловливалась прежде всего промышленными интересами, вдруг назрела потребность в "очеловечивании" и в то же время укреплении языка, с помощью которого человеку суждено было общаться с машиной. Языков программирования уже тогда было более чем предостаточно, однако такое же несметное количество не годилось для решения критических задач, в которых не было места грубым ошибкам и недоработкам. В ту пору уже доминировал Си. Вскоре на смену ему пришел Си++, - более изощренный и мощный, нежели первичное детище Карнигана и Ритчи. Наряду со многими нововведениями Си программисту в руки было вложено новое средство - Объект. Это резко упростило некоторые вещи (стоп!, не некоторые) - в тот период все перевернулось с ног на голову, - программист, оперирующий аморфными понятиями, теоретическими "субъектами" и прочими персонажами из сказки о clsMyObj, решал те же задачи, что и программист, не решившийся бросить процедурный (последовательно-алгоритмический - устаревш. информ.) язык, выполнял свою работу качественней, быстрей: и, несомненно, с бОльшим удовольствием и с меньшими услиями - один из попутных "козырьков" ООП - использование готового кода.

Все так, однако бытует легенда, будто Объекты зародились еще задолго до появления первого языка программирования. Ну: не будем ломать голову над тем, что в данной статье как раз и не принципиально, (язык Си взят как пример по причине безоговорочного господства на поприще низкоуровневых языков и по сей день) - оставим сии измышления археологам, и признаем лишь тот факт, что постепенно все, даже самые молодые и "вторичные", детские (Basic) и студенческие (Pascal) языки программирования стали обзаводиться своей объектной стратегией. И хотя некоторые только имитировали ООП, тенденция все же дошла до наших дней. До сих пор на пике популярности книги по Объектно-Ориентированному программированию, причем не применительно к какому-либо конкретному языку, а освещающие принципы, идеологию и образ "объектного мышления" Сами ОО-специалисты называют это "ОО-философией". По своей природе и идее ООП не привязывается к конкретному языку - это принцип построения программы, ее структурная схема. Это - глубже, чем можно описать в рамках сей публикации, потому как затрагивает не только лишь период проектирования модели приложения, его концепции и схемы, - образа, если хотите: Это - поистине образ мышления: * * *

ООП подразумевает в первую очередь наличие классов. Классы - это как-будто самый мелкий элемент той структуры, которая и формирует Объектно-Ориентированную концепцию в целом. Каждый класс имеет свои свойства, свои методы свои события. Непременным свойством истинного ОО-языка является инкапсуляция, что означает "закупоренность" механизма того или иного явления в Объектах. Вообще, инкапсуляция основана на области видимости (Scope) внутренних переменных Класса. Таким образом программист зачастую использует объекты, созданные другими программистами, и абсолютно не задумывается, как все это устроено, он просто доверяет "производителю объекта" и всецело занят лишь решением задачи, поставленной конкретно ему. Яркий пример такого подхода к созданию приложений при помощи инкапсулированных механизмов - элементы управления (ActiveX-компоненты), которые, к стати, можно использовать во всех поддерживающих ActiveX-технологию языках программирования. Одним словом, вы добавляете в проект текстовое поле, не задумываясь о том, как реализована, например, прорисовка его текста.

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

Второй "кит" - наследование. Что это значит? Это значит, что Объекты (Классы, Коллекции) могут перенимать некоторые свойства у своих прародителей. Как - это зависит от того языка, на котором пишется программа. Однако в любом случае картина та же: это приводит к повторному использованию уже написанного однажды кода. Наследование-то по определению заставляет что-то у кого-то наследовать, значит, можно создать свое текстовое поле на основе уже существующего класса TextBox (в Visual Basic), причем новый Класс (назовем его EnhancedBox) наделен всем тем, чем располагает его стандартный родитель, плюс новыми свойствами, определяемыми его создателем. Никуда не денутся свойства Font, Alignment, Multiline, - если их специально не "ампутировать". На основе наследования, - пусть даже искусственного, - в Visual Basic выросла и техника Cубклассинга (Subclassing), при которой компоненты наделяются новыми свойствами. Чаще термин употребляется применительно к элементам управления. На рисунке показан фрагмент работы с ClassBuilder. В текстовое поле необходимо ввести имя класса-родителя, или же оставить Based on: (New class). Я выбрал первичный класс cLink, поэтому новый Класс cLoadedLink унаследовал все его "аксессуары". О ClassBuilder читайте ниже.

Третий "кит" ООП - полиморфизм. Вообще, это уже из области искусственного интеллекта J. В данном случае речь идет о той роскоши, за которую стоит выдерживать и немногие издержки ООП (однако же выигрыш очевиден и бесспорен!). Объекты, располагающие одноименными методами или свойствами, могут с легкостью управляться в ходе программы, независимо от того, что эти одноименные свойства и методы выполняют абсолютно разные действия, в отношении абсолютно разных классов, да и устроены по-разному. Например, возьмем свойство Font, широко распространенное во многих компонентах:

Private Sub Command1_Click()
   Dim Ctl As Control
   For Each Ctl In Me.Controls
       Ctl.FontName = "Courier"
   Next
End Sub

Таким образом, мы избежали тщательного учета каждого элемента управления на нашей форме, и упомянули сразу всех при помощи системы For Each:In : Next (Для Каждого: В_Коллекции: Стоп). Конечно, ничто не мешает поступить по-иному. Это - проще: Но при условии, что на форму динамически не добавляются компоненты.

Впрочем, указанная конструкция - явный атрибут ООП, поскольку For Each работает лишь с коллекциями. Коллекции - это своеобразные классы, являющиеся учетными наборами других классов. Чем удобны коллекции? Прежде всего методами Add, Remove, свойствами Item. Используя наряду с другими стандартными для классов методами Add и Remove, программист имеет возможность пополнять коллекцию, удалять из нее определенные с помощью Item(Index) элементы. Любая коллекция имеет метод Clear.

Допустим, мы создали собственный Интернет-загрузчик. Это повлечет за собой работу со списками гиперссылок, их хранением и управлением.

Для того, чтобы программа оказалась эффективной и более-менее компактной, необходимо избавить ее от излишней конкретики, во всяком случае, там, где это возможно. Например, гиперссылка может вести как к графическому ресурсу, так и к обычной гипертекстовой странице: а может это запрос к удаленной базе данных?. Поэтому целесообразно было бы создать одноименные методы для обоих случаев - DownLoad, Save и так далее. Тогда великолепен код:

For Each cLink In cLinks
     cLink.DownLoad
     cLink.Save
Next
cLinks.Clear

Теперь можно забыть создание Классов cLink и cLinks как кошмарный сон. Впереди -лишь удовольствие от работы с "запечатанными" методами/свойствами /событиями:

Это и есть полиморфизм в примитиве. Почитатели ООП уже не мыслят себе процесса написания программы без Классов, свойств, методов и событий. Бытует также понятие Объектно-Ориентированного Дизайна (ООД).

Природа Свойств, Методов и Событий. Перечислимые типы

Механизм Классов в Бейсике реализован весьма просто и не должен вызывать особых затруднений. В модуле класса для каждого свойства объявляется локальная (для Класса) переменная-посредник в схеме Класс--пользователь. Присвоение свойству Объекта нового значения или считывание его - не более чем общение с этой переменной.

Не все так сложно, уважаемый читатель. Как-то в цикле "Мышление в стиле Visual Basic" была затронута тема окна сообщения - проверенного фундамента, на котором нетрудно построить общие представления неподготовленного читателя о функциях, процедурах, аргументах. Там же была рассмотрена способность оболочки Бейсика к автозавершению кода. Действительно, вследствие того, что код Бейсика компилируется еще на стадии набора его с клавиатуры (!), те или иные лексемы могут быть распознаны VB, или наоборот - ждешь всплывающих "тултипов" - минуту, две (шутка), а их все нет и нет. Помните: Бейсик - для "непрограммистов". Visual C++ - наоборот, поэтому там подсказок ждать не приходится.

Перед тем, как сесть и написать первую строку кода, ООП-почитатель тщательно продумывает структуру приложения, причем даже сидя с карандашом и бумагой, - не за клавиатурой. Когда он, наконец, примет решение, что такие-то методы должны быть одноименными (из вышеперечисленных соображений), такие-то объекты должны входить в такие-то коллекции/наборы, а такие коллекции - в другие коллекции, и когда придет к выводу, что система совершенна, - начнет проект!

Объектно-Ориентированный подход немыслим без UDT - User Defined Types, - пользовательского типа данных. Объявив такой тип в своей программе, можно объявлять и переменные этого типа. Процедура Type "лепит" из встроенных типов Бейсика то, что нужно пользователю для создания другого, нового типа. Так, естественен код в ОО-приложении:

Public Type HyperLink
    Address As String
    Port As Long
    ContentType As String
End Type
Dim MyLink As HyperLink

При этом MyLink уже имеет необходимые нам свойства веб-ссылки: адрес, порт, тип данных, и так далее.

Итак, если в проекте Visual Basic правильно объявлены все Типы, Классы, Коллекции, IDE VB предлагает свои варианты кода в виде выпадающих вариаций. Очевидно, что такие действия со стороны среды разработки заметно упрощают программирование: в большинстве случаев можно не знать досконально тот или иной компонент и действовать интуитивно.

Visual Basic располагает также таким средством как перечислимые типы данных. К ним можно отнести, например, кнопки в окне сообщения: vbOkOnly, vbYesNoCancel. Каждый раз при указании процедуры или функции MsgBox на экране появляется соответствующий список возможных значений. Кроме того, Классы, Коллекции, их свойства, методы и события, а также константы, объявленные в Классе проекта наглядно представлены в Броузере Объектов.

Подключение к проекту библиотек типов (*.tlb) и динамически подключаемых библиотек (*.dll) позволяет "достучаться" к Объектам и типам других приложений. Они-то и выполняют большую часть черной работы по объявлениям и типам. Отыскав в диалоговом окне References (кнопка Browse) библиотеку типов, пользователь пополняет содержимое Броузера Объектов - чьи-то Классы полностью готовы к употреблению.

Поистине к глобальным последствиям привело появление OLE, COM - Component Object Model, DCOM - Distributed Component Object Model, позволяющие, грубо говоря, относительно свободно обмениваться информацией между приложениями. Например, двусторонне обмениваться компонентами с Internet Explorer, MS Word, и другими серверами. Информация о доступных Классах находится в Системном Реестре в ключе HK_CLASSES_ROOT\CLSID.

Создание Класса или Коллекции в среде Visual Basic может осуществляться как непосредственно через написание всего необходимого кода, так и с использованием надстроек, например, ClassBuilder`a.

В открытом проекте:

Меню Project--Add Class Module

Выбор элемента списка ClassBuilder приведет к появлению Построителя Классов. С помощью этого мастера в визуальном режиме можно за пятнадцать минут создать обширнейшую иерархию классов, наборов (коллекций), создать для каждого класса свойства, события и методы, однако ClassBuilder именует переменные и присваивает им тип данных не совсем так, как хотелось бы, поэтому ручная работа неизбежна. Впрочем, не только по этой причине J.

Однако при всех удобствах Построителя Классов это чудесное средство все же рекомендуется в большей степени начинающим ООП-исследователям Visual Basic 5, 6. Так называемые гуру ООП предпочитают порождать Объекты "руцями": компактно, лаконично, строго. Седьмая версия многострадального Васика, судя по анонсам Microsoft, "заставит пересмотреть познания этого языка".

В среде разработки Visual Basic имеется еще великолепное творение, предназначенное помочь в "разборках" с Объектами, Коллекциями, Константами, объявленных в этих Классах и всем, что с ними связано - Броузер Объектов.

Нажав F2, программист может воочию убедиться в правильности созданной им иерархии Классов. Сопутствующие подсказки и система элементарного поиска - вот что нужно тому, кто здесь впервые. Однако ObjectBrowser используется отнюдь не только в целях изучения собственных творений: создав Reference ("зависимость") к чужим распределенным (Distributed) Объектам, можно изучать чужие Классы, наблюдать, как они устроены, а затем грамотно использовать.

Рисунок (***) изображает подключенную к обычному проекту Объектную модель Microsoft Word 8 (меню Project--References, в появившемся диалоге выбираем Microsoft Word 8 Type Library). Таким образом, мой проект имеет полную власть над создаваемым документом чужого программного продукта, причем я не имею ни малейшего понятия, как происходит добавления стиля в Normal.dot, я также не знаком с форматами файлов doc и dot, однако это не мешает мне и другим программистам читать и создавать "доки". Вспомните, например, экспорт в формат Microsoft Word из FineReader компании ABBYY (хотя здесь и основная нагрузка ложится на технологию OLE, программист все же видит внешнее приложение как "Объект", наделенный своими свойствами, событиями и методами):

Для одних языков программирования ООП - родная среда, в то же время другие, - такие как Visual Basiс, - лишь имитируют ООП, в частности, такое понятие, как полиморфизм. Что касается будущего Бейсика - ждем следующей версии (в составе Visual Studio .NET), где специалистам-Бейсиковцам придется заново проходить курс молодого бойца - осваивать VB .NET (7), так как изменений хоть не так много, однако они есть, причем радикальные. Итак, по данным Microsoft, VB .NET - "нормальный Объектно-Ориентированный язык программирования".

Извечная классовая борьба Си++ и Визуального Бейсика

Начну, пожалуй, с того, что никогда ни Бейсик, ни Visual Basic ни с кем не соперничали, - сам по себе первозданный Basic - мягко говоря, не такое уж мощное средство. Однако, облаченный в оболочку (IDE), с API через плечо, с ActiveX-совместимостью - через другое и достаточно "закупоренный" для посредственного круга пользователей, позволяет смело соперничать с Delphi (из той же оперы: сначала повзрослел Паскаль до статуса Объектного, затем - признание), Visual C++ - молниеносно создавать сложнейшие программы для Windows. Runtime-файлы msvbvm*0.dll содержат стандартный ассортимент для UI, - в виде экземпляров классов, присутствующих сейчас в системе. Поэтому голова разработчика на VB болит гораздо меньше и реже по поводу реализации пользовательского интерфейса, нежели у программиста на С++. (Будем говорить так: вообще не болит). И пусть программист на С++ бъет себя в грудь: мол, его язык хоть сложнее, зато мощнее, быстрее, компактнее и: ОС Windows - продукт С++, поэтому творить для Окон нужно на Си++. Однако, уважаемый читатель, следует запомнить: скорость в работе Си-программ почти не отличается от скорости современного (v.5, 6) Бейсик-софта (для того, чтобы заметить разницу, необходимо писать специальные счетчики-секундомеры). Говорят, на Си пишут автономные приложения (это те, которые вмещаются на 3,5"-диски и работают без DLL), однако теперь это редкость - подавляющее большинство ПО, написанного на солидных языках все равно обращаются к библиотекам. Потому что программирование для графической среды - а именно Windows - без готовых классов, стандартных графических компонентов, без обращений к Реестру - настоящая преисподня. Кроме того, единство стиля - часть успеха. Скажу больше: VB .NET восполнит прорехи в этой области - теперь создание консольного приложения на Бейсике больше не "трюк" и выполняется примерно в три-четыре строки кода.

Итак, Microsoft Visual C++ позволяет создавать приложения, используя готовые продукты. Среди них не последнее место по "употребляемости" занимает библиотека Microsoft Foundation Classes (MFC).

MFC, по сути, является аналогом готовых компонентов, огромнейшим количеством которых, например, обладает Delphi, Borland C++ благодаря VCL (Visual Component Library) - различия могут состоять лишь в визуализации тех или иных классов, но факт остается фактом: и те и другие библиотеки являются полноценным законченным продуктом. Если уважаемый читатель не вздумал сочинять PictureBox`ы, Кнопки и Списки с нуля - самое время использовать чьи-то классы в полный рост.

Не стану рассказывать о роли классов в С++, - вне сомнения, что С++ является сугубо Объектно-Ориентированным языком программирования, и это уже знают сегодняшние школьники. С другой стороны, Visual Basic 5 и выше - имитатор ООП. (Помнится, ранее это был даже не компилятор - другими словами, "имитатор исполняемого кода"). Да, Бейсик до сих пор БЫЛ почти ОО-языком. Почти? Дело во втором немного странном "ките" Бейсика девяностых: при создании Классов в VB 5, 6, якобы наследующих признаки родителей, на самом деле по наследству передаются лишь родительские интерфейсы. Однако все здесь, опять-таки, весьма относительно: поскольку ООП является лишь тем ментальным аспектом процесса проектирования, так сказать условностью, абсолютно не влияющей на компилируемый код, за исключением лишь компактности и удобства для программиста (можно даже допустить - синтаксическим и структурно-лингвистическим расширением), а также практически не ведет к явному ускорению кода, стоит ли грешить на Бейсик как на лже-Объектный инструмент?

Эпилог

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

Более подробно о принципах ООП в среде Visual Basic 5, 6 читайте в цикле "Мышление в стиле Visual Basic".