Последний раз обновлено 27.06.01
|
Существует достаточно много работ посвященных созданию программ с использованием ООП. Однако, мне не попадалось ни одной, которая бы в полной мере акцентировала внимание на собственно особенностях ООП как методе решения задач, а не на особенностях реализации ООП в каком-либо конкретном языке программирования или использования готовой библиотеки классов. Это не позволяет писать программы общего назначения программисту не высокой квалификации без существенной и трудоемкой переработки информации.
Трудность возникает именно в принципах, применяемых в ООП для создания программы, а не в технической, т.е. синтаксической ее реализации. Другими словами, как получить то, что можно описать на С++. Предложенная работа пытается ответить на этот вопрос. Она не для профессионалов, и позволяет создавать не лучший код, но вполне объяснимый, "без магии", и, самое интересное, вполне работоспособный.
Попробуем протянуть цепочку от постановки задачи, получения модели, описания ее на С++ и получения готового результата. Предполагается умение программировать на структурном языке и знакомство с синтаксисом С и С++ для программирования без применения средств ООП.
Один из широко используемых способов создания объектной модели заключается в применении паттернов (шаблонов) проектирования, которые определяют то, как формируется система объектов программы.
Я рекомендую книгу "Шаблоны проектирования", А. Шаллоуей, Дж. Р. Тротт, которую легко использовать, если первые навыки получения объектных моделей после прочтения этого текста будут получены. Аннотация к книге .
Эта работа не описание алгоритмов. Сказать по секрету, я не знаю толком ни одного, кроме метода сортировки пузырьком. Так же это не договоренности о том, как и что включать в имена символов с подчеркиванием и заглавными буквами, каким регистром обозначить константы и т.д. Здесь не ставится задача ознакомить кого-либо с хитростями использования С++ или его последним стандартом, этого не требуется для начального обучения ООП.
Многие знакомы с программированием на обычных структурных языках, таких как С. Думается, что не следует бездумно выбрасывать накопленый опыт, а стоит попытаться использовать его для ООП и попытаться объяснить объектные программы с учетом знания структурных, сравнить их между собой.
Реализация языка определяет способ создания программы, предлагая некоторый набор операций и правил, но структура ООП программы определяется не только этим. Многие проблемы при создании программы происходят от того, что некоторые пытаются ООП объяснить через С++, т.е. ставят телегу впереди лошади. "ООП через призму С++", если для кого-то этого достаточно, то это хорошо, и не нужно читать дальше. Я поддерживаю мнение, что возможность писать программы на готовых объектных библиотеках, составленных профессионалами, и зная минимум о методе ООП это миф.
На мой взгляд, разница при написании программ между ассемблером и С меньше, чем между С и С++, несмотря на внешнюю схожость последних. ООП как бы предлагает новый уровень типизации для структурного языка, как сам структурный язык предлагает типизацию для ассемблера.
Данная работа выросла из попыток применять ООП на практике. При программировании возникали вопросы, и ответы на них я и постарался записать, пытаясь, на сколько это возможно, не привязывать их к примеру, а придать им общий вид. "Может это вам и не нравится, но это работает" - цитата не помню из кого.
Для тех кто пользуется готовыми предметными библиотеками (OWL, MFC) это может быть не интересным, т.к. там важнее не почему, а что, где и как. Возможно, будет интересно для тех, кто пытается ( или будет ) использовать ООП для программ общего назначения. Что такое программа общего назначения? Это та часть вашей программы, которая выделяет ее из всех других программ мира и привязана только к задаче.
Знание тонкостей языка С++ и методов создания объектов может быть получено только из опыта написания программ и прочтения руководств по С++, любые другие объяснения будут поняты поверхностно. Встретив проблему в реальной задаче и разрешив ее, получим связь проблемы, решений и контекста, и вариации этих трудностей будут также разрешимы, это кажется лучше, чем запоминание множеств вариантов решений.
Разумеется, есть необходимость знать в сравнении между собой большое число стандартных реализаций объектов и их описаний на С++, но это за рамками данной работы, за рамками необходимого для первых шагов в мире ООП и требует от автора достаточного практического опыта, чтобы давать подобные оценки. А возможно ли написание каких-либо программ без этого? Каких-либо возможно, а по мере накопления опыта будут накапливаться нужные знания. Определенную помощь может оказать ряд работ посвященных именно расширению познаний в ООП, но все они требуют элементарных знаний об объектной программе.
В структурном программировании нет смысла в большинстве случаев подробно излагать для чего нужны if, while, for и goto. Это понятно интуитивно, просто из бытового здравого смысла. В С++, в той части, которая касается объектных свойств, это не так. Многие синтаксические конструкции при первом просмотре вызывают недоумение, но ведь кто-то эту конструкцию на свет произвел, значит чем-то руководствовался.
Перечисления ключевых слов, их взаимных сочетаний в виде таблиц и исключений из правил этих сочетаний вгоняют в тоску даже самых стойких. Мало кто в состоянии запомнить столько текста, а к чему все это - остается не понятным, при написании программы вопросов все больше и приходится их выяснять "методом математического тыка". А вопросы простые, и не ясно, как их удавалось избегать в примерах.
Это безобразие происходит из-за того, что либо просто описана предметная библиотека, давая то количество ООП которое минимально необходимо ( я думаю, что это не даст возможности нормально написать программу все равно ), либо посвящено целиком реализации ООП на языке программирования С++, предполагая, видимо, знание ООП. Даже создается ощущение, что ООП какая-то глупая надстройка над С для написания программ Windows, наследования из точек кругов и квадратов и моделирования океанов и собак.
А ведь ООП требует особого подхода к разработке программы, хотя, наверно, лучше будет назвать этот подход естественным. Одно из проявлений этого подхода то, что довольно долго создается модель, а затем сравнительно быстро описывается на языке ООП, это не похоже на структурную программу, в которой акцент часто смещен на кодирование, на описание, а не на создание. Объектную модель частично можно реализовать и на структурном языке, но это будет существенно сложнее.
Хотя бы немного поняв как работает объектная модель программы, очень быстро и легко ознакомиться с особенностями ее реализации на каком-то языке, это будет даже интересно, и все эти несчастные таблицы выродятся в справочные данные, чем по сути и являются. А не наоборот, глядя на конструкцию раздумывать о путях мысли автора.
При описании ООП я попробую ограничиться (за исключением нескольких случаев) одним языком программирования, вернее, парой: С/С++. Во-первых, я сам детально даже их не знаю (использую понятные и необходимые мне подмножества языка), во-вторых, я слышал, конечно, что есть еще какие-то языки, но программы на них не писал, поэтому сравнивать с ними и приводить их в пример для меня нет смысла, для других не полиглотов, видимо, тоже, поэтому, временно, забудем о других языках.
Наибольшая ценность этого текста, может быть, в том, что он создан по моим заметкам, которые показывают то, что мне было непонятно, когда я хотел освоить С++ после С. Человека знакомого с ООП и весьма смутно представляющего себе что это такое должны волновать разные проблемы при написании программы, это очевидно. По этой причине я стараюсь минимально модифицировать исходный текст.
Что же это за простые вопросы которые подвигли меня на подвиг их описания? Перечислю несколько:
Просто надоело все перечислять. Вопросы не сложные, но на новичка оказывают сильное останавливающее действие отсутствием внятного ответа или самим фактом того, что он их задал. Варианты ответов, которые есть здесь на эти и другие вопросы, достаточно просты для понимания и применимы на практике. Все примеры примитивны, для более сложных в приложении есть архивы исходных текстов.
Всегда, в подобных случаях, есть опасность придти к вопросам и ответам типа:
- Господа, вы знаете что такое кресло?
- Кресло это стул.
- А вы знаете что такое кювет?
- Это длинная канава по обеим сторонам дороги.
Но я постараюсь не пересечь эту грань между основным и банальным.
Буду использовать ряд сокращений. Сокращения хороши не только потому, что мне быстрее их набирать, но еще и потому, что текст вам легче читать: вместо трех слов только одно.
Я считаю, что полноценно программировать на С++ не зная СП и языка С нельзя, хотя профессионалы и говорят, что С только мешает и вырабатывает плохой стиль. В том, что они говорят, большая доля истины. Но я думаю, что знание английского языка не выработает плохой стиль применения немецкого. Проблема стиля - это проблема человека, который, видимо, пишет программу, или говорит на любимом языке, не задумываясь о том, кто его слушает. Либо человек преувеличивает свои знания в каком то из языков.
Предлагаемый мной вариант объектной модели основан на следующем:
Можно использовать все приемы и алгоритмы структурной модели. Вероятно, есть и другие способы построить О-модель, но мне они не известны.
Я надеюсь, что все получилось достаточно связно, и читать лучше с начала, чтобы одинаковыми словами мы называли одинаковые предметы, но можно выделить несколько отдельных, более-менее независимых частей:
Я решил добавить сюда еще вот это, как бы оправдываясь перед читателем.
Когда я пытался писать свои первые программы, мне на глаза попалась книжка по языку Паскаль, в которой помимо описания языка, давалось описание того, как получить программу из задачи и почему. Книжка (автор и название я забыл, если кто знает, может мне напомнить) не очень толстая, да и не новая, не по новейшему стандарту, но, я уверен, что она существенно и надолго изменила мой взгляд на программирование.
Я не занимаюсь профессионально программированием, но по мере сил слежу за его развитием, это мое хобби, но я с удивлением обнаружил, что не могу найти ничего подобного для ООП. То ли люди теперь думают иначе, то ли еще что не так, но я твердо знаю, что не умея на бумажке словами или рисунками объяснить что вы хотите, нельзя написать программу, сколько новейших стандартов и языков не запомни, и могу с уверенностью сказать, что схема программы, ее модель, не зависит от языка программирования за исключением деталей и может быть описана даже обычными словами. Я не использую Паскаль, но для С использую метод создания программ, который годится для обоих. Таким образом построенная программа может быть реализована как на Паскале, так и на С. Это происходит потому, что оба языка относятся к структурным. Можно построить программу так, что ее нельзя будет или очень сложно реализовать на С и Паскале, а можно на С++, Смолток и им подобным. Именно этим вещам и посвящена эта работа.
Мне не удалось применить структурные навыки для написания программ ООП, синтаксис ООП для этого просто избыточен, после, как я уже говорил выше, попыток на практике применять ООП и прочтения различных доступных мне источников получилось вот это, этот текст, может быть, кому то покажется лучше чем ничего. Конечно эта работа не претендует на такую книжку для ООП, но, если вы знаете лучше, буду рад услышать ссылки.
Хочу еще раз подчеркнуть, что эта работа не описание С++. Не требуется для изучения ООП (в той мере, какая используется в данном тексте) новейшего стандарта С++, старый Борланд 3.1(не 3.0) вполне подойдет, он достаточно дружественный и работает на любой машине с процессором не ниже 386.
Я извиняюсь за орфографические и пунктационные ошибки, которыми переполнен текст этой работы и разнообразные неточности, только надеюсь, что они не искажают и не сводят к нулю главную идею текста. У меня пока нет возможности, а если вы попробуете сами набить столько текста, то вы меня поймете (и особого желания) исправить их все.
Для тех, кто обладает определенным опытом программирования на структурных языках и считающих, что они уже достигли значительных высот мастерства, переход к новой методике ООП может оказаться мучительным: жалко бросать нажитое и мыслит человек в терминах функций и данных, с которыми эти функции работают. Да и зачем это надо?
Про ООП говорят ( в сравнении со структурной программой ):
int. Другими словами, ООП язык - универсальный язык который подстраивается под задачу, а не наоборот.
В наличии имеются специальные среды разработки для популярных предметных областей, эмулирующие задачу и позволяющей интерактивно, как на бумажке, и на языке задачи, скрывая синтаксис С++, разрабатывать программу, причем программирование не обязательно вырождается в программировании сложной задачи на Бейсике. Даже если для вашей предметной области такого нет или качество имеющейся не устраивает, иногда возможно создать свою.
ООП идеально для программ-однодневок. Некоторые используют компьютер для задач, для которых он вобщем то и предназначен: забирать на себя большое количество рутинных операций в разного рода отраслях человеческой деятельности. Работа такой задачи сводится к "что-то посчитать", после чего программу выкидывают.
Нельзя создать универсальную программу для всего. Но если создание и отладка уникальной программы займет больше времени, чем сделать все руками, то человек будет выполнять простые и однообразные действия сам, ошибаясь и путаясь.
Повторное использование кода развито настолько сильно, что можно создавать и использовать библиотеки качеств программных объектов: записываемость на диск, отображаемость в окне и отклики на сообщения Windows, возможность образовать список и т.п. Все эти качества просто добавляются к нужному объекту, они уже отлажены отдельно.
Предыдущие пункты определяют то, что на первый взгляд не очевидно. Для небольшого коллектива или одного программиста невысокой квалификации или даже для пользователя самой предметной области: математику, инженеру, появляется возможность разрабатывать задачи, к которым он бы не смог бы даже подступиться на обычном структурном языке, без риска не закончить до смерти. Это такая же помощь, как для архитектора наличие системы CAD против ватмана и карандаша.