Структурное программирование представляет собой наиболее крупное достижение в этой области на данный момент. При том, что почти все имеют общее понятие о нем, почти никто не может дать конкретного и четкого определения данному термину. Структурное программирование ставит основной целью писать программы наименьшей сложности, заставляя программиста ясно мыслить, облегчая восприятие программы. Текст ее необходимо делать таким, чтобы он был читаем сверху-вниз. Это условие нарушается, если в программном коде встречаются операторы go to, так как они нарушают структуру всего отрезка программы. При том, что этот показатель нельзя считать самым удобным, все же можно сказать, что наличие в программном коде данного оператора является самым бросающимся в глаза типом нарушения структуры. Тела модулей и применяемые базовые конструкции должны обладать устойчивостью к аппаратным сбоям, ошибкам в программах и искажениям исходных данных.

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

Простой последовательности;

Условий или альтернатив;

Повторений, то есть циклов и итераций.

Использоваться может один или два любых вида одновременно. Каждой структуре присуща единая черта - единственная точка передачи управления в структуру и единственная точка входа в структуру. Такой вид конструкции имеет дисциплинирующее и систематизирующее значение.

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

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

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

Если говорить о позиции относительно ранее упомянутого оператора go to, то его стоит избегать использовать везде, где только возможно, однако это никак не должно отражаться на ясности программы. Иногда использование данного оператора оказывается просто необходимым для выхода из какого-то отрезка программы или цикла, а также для того, чтобы избежать появления слишком углубленных развилок, тем более, что переход связан с более нижними уровнями программ. При этом структура программы так и остается легко читаемой сверху вниз. Самый худший данного оператора связан с переходом снизу вверх.

Для облегчения чтения программы часто добавляют пустые строки между разделами. Стоит писать текст программы со сдвигами, чтобы можно было прочитать последовательность действий и количество вложений.

Структурная

• Разделение ответственности :

Шаблон: программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков . Предложена в 70-х годах XX века Э. Дейкстрой , разработана и дополнена Н. Виртом .

В соответствии с данной методологией

1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:
   • последовательное исполнение - однократное выполнение операций в том порядке, в котором они записаны в тексте программы;
   • ветвление - однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;
   • цикл - многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).
   В программе базовые конструкции могут быть вложены друг в друга произвольным образом, но никаких других средств управления последовательностью выполнения операций не предусматривается.
2. Повторяющиеся фрагменты программы (либо не повторяющиеся, но представляющие собой логически целостные вычислительные блоки) могут оформляться в виде т. н. подпрограмм (процедур или функций). В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы . При выполнении такой инструкции выполняется вызванная подпрограмма, после чего исполнение программы продолжается с инструкции, следующей за командой вызова подпрограммы.
3. Разработка программы ведётся пошагово, методом «сверху вниз».

Сначала пишется текст основной программы, в котором, вместо каждого связного логического фрагмента текста, вставляется вызов подпрограммы, которая будет выполнять этот фрагмент. Вместо настоящих, работающих подпрограмм, в программу вставляются «заглушки», которые ничего не делают. Полученная программа проверяется и отлаживается. После того, как программист убедится, что подпрограммы вызываются в правильной последовательности (то есть общая структура программы верна), подпрограммы-заглушки последовательно заменяются на реально работающие, причём разработка каждой подпрограммы ведётся тем же методом, что и основной программы. Разработка заканчивается тогда, когда не останется ни одной «затычки», которая не была бы удалена. Такая последовательность гарантирует, что на каждом этапе разработки программист одновременно имеет дело с обозримым и понятным ему множеством фрагментов, и может быть уверен, что общая структура всех более высоких уровней программы верна. При сопровождении и внесении изменений в программу выясняется, в какие именно процедуры нужно внести изменения, и они вносятся, не затрагивая части программы, непосредственно не связанные с ними. Это позволяет гарантировать, что при внесении изменений и исправлении ошибок не выйдет из строя какая-то часть программы, находящаяся в данный момент вне зоны внимания программиста.

Теорема о структурном программировании:

Основная статья: Теорема Бома-Якопини

Любую схему алгоритма можно представить в виде композиции вложенных блоков begin и end, условных операторов if, then, else, циклов с предусловием (while) и может быть дополнительных логических переменных (флагов).
Эта теорема была сформулирована итальянскими математиками К. Бомом и Дж. Якопини в 1966 году и говорит нам о том, как можно избежать использования оператора перехода goto .

История

Методология структурного программирования появилась как следствие возрастания сложности решаемых на компьютерах задач, и соответственного усложнения программного обеспечения. В 70-е годы XX века объёмы и сложность программ достигли такого уровня, что «интуитивная» (неструктурированная, или «рефлекторная») разработка программ, которая была нормой в более раннее время, перестала удовлетворять потребностям практики. Программы становились слишком сложными, чтобы их можно было нормально сопровождать, поэтому потребовалась какая-то систематизация процесса разработки и структуры программ.

Наиболее сильной критике со стороны разработчиков структурного подхода к программированию подвергся оператор GOTO (оператор безусловного перехода), имевшийся тогда почти во всех языках программирования. Неправильное и необдуманное использование произвольных переходов в тексте программы приводит к получению запутанных, плохо структурированных программ (т. н. спагетти-кода), по тексту которых практически невозможно понять порядок исполнения и взаимозависимость фрагментов.

Следование принципам структурного программирования сделало тексты программ, даже довольно крупных, нормально читаемыми. Серьёзно облегчилось понимание программ, появилась возможность разработки программ в нормальном промышленном режиме, когда программу может без особых затруднений понять не только её автор, но и другие программисты. Это позволило разрабатывать достаточно крупные для того времени программные комплексы силами коллективов разработчиков, и сопровождать эти комплексы в течение многих лет, даже в условиях неизбежных изменений в составе персонала.

Методология структурной разработки программного обеспечения была признана «самой сильной формализацией 70-х годов». После этого слово «структурный» стало модным в отрасли, и его начали использовать везде, где надо и где не надо. Появились работы по «структурному проектированию», «структурному тестированию», «структурному дизайну» и так далее. В общем, произошло примерно то же самое, что происходило в 90-х годах и происходит в настоящее время с терминами «объектный», «объектно-ориентированный» и «электронный».

Перечислим некоторые достоинства структурного программирования:

1. Структурное программирование позволяет значительно сократить число вариантов построения программы по одной и той же спецификации, что значительно снижает сложность программы и, что ещё важнее, облегчает понимание её другими разработчиками.
2. В структурированных программах логически связанные операторы находятся визуально ближе, а слабо связанные - дальше, что позволяет обходиться без блок-схем и других графических форм изображения алгоритмов (по сути, сама программа является собственной блок-схемой).
3. Сильно упрощается процесс тестирования и отладки структурированных программ.

См. также

Ссылки

Wikimedia Foundation . 2010 .

• Махаджанапады
• Camel

Смотреть что такое "Структурное программирование" в других словарях:

Структурное программирование - методология и технология разработки программных комплексов, основанная на принципах: программирования сверху вниз; модульного программирования. При этом логика алгоритма и программы должны использовать три основные структуры: последовательное… … Финансовый словарь

структурное программирование - struktūrinis programavimas statusas T sritis automatika atitikmenys: angl. structured coding; structured programming vok. strukturelle Programmierung, f rus. структурированное программирование, n; структурное программирование, n pranc.… … Automatikos terminų žodynas

Структурное программирование - 46. Структурное программирование Structured programming Источник: ГОСТ 19781 90: Обеспечение систем обработки информации программное. Термины и определения … Словарь-справочник терминов нормативно-технической документации

Программирование - Эта статья должна быть полностью переписана. На странице обсуждения могут быть пояснения. У этого термина существуют и другие значения, см. Программи … Википедия

ПРОГРАММИРОВАНИЕ - 1) процесс составления программы, плана действий. 2) Раздел информатики, изучающий методы и приёмы составления программ. С долей условности П. как дисциплина разделяется на: теоретическое, изучающее матем. абстракции программ (как объектов с… … Физическая энциклопедия

Программирование основанное на прототипах - Прототипное программирование стиль объектно ориентированного программирования, при котором отсутствует понятие класса, а повторное использование (наследование) производится путём клонирования существующего экземпляра объекта прототипа.… … Википедия

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

Компьютерное программирование - Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ | Проектирование | Реализация | Тестирование | Внедрение | Сопровождение Модели / методы Agile | Cleanroom | Итеративная | Scrum | RUP | MSF | Спиральная | … Википедия

Неструктурированное программирование - Структурное программирование методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. Предложена в 70 х годах XX века Э. Дейкстрой, разработана и дополнена Н. Виртом. В … Википедия

Компонентно-ориентированное программирование - Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия

Книги

• Дисциплина программирования , Дейкстра Э.. Книга написана одним из крупнейших зарубежных специалистов в области программирования, известным советскому читателю по переводам его книг на русский язык (например, «Структурное…

Структурное программирова­ ние - это первая законченная методология программирования. Структурное программирование оказало огромное влияние на раз­витие программирования. Этот метод применялся очень широко в практическом программировании и по сей день не поте­рял своего значения для определенного класса задач.

Структурный подход базируется на двух основополагающих принципах:

1 - это использование процедурных языков про­граммирования (Алгол, Паскаль, СИ);

2 - это последовательная декомпозиция ал­горитма решения задачи сверху вниз.

Задача решается применением последовательности действий. Первоначально задача формулируется в терминах входа-выхода. Это означает, что на вход программы подаются некоторые данные. Программа работает и выдает ответ.

После этого начинается последовательное разложение всей за­дачи на более простые действия.

Например, если нам необходимо написать программу проверки правильности адреса, то вначале мы ее запишем следующим образом:

Сверить адрес с базой имеющихся адресов

Если результат проверки положителен, напечатать Да,

в противном случае напечатать Нет.

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

program check_address (input, output); varan_address: Address; begin read_address(an _address);

if (check_database(an_address)) then

writelnTMIa") ; else

Эта программа использует процедуру read _ address для чте­ния адреса и процедуру check _ database для сверки прочитанно­го адреса с информацией в базе данных. Теперь мы можем продол­жить процесс составления программы для процедур следующего уровня: чтение адреса и сверки с базой данных.

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

Программа компонуется с заглушками и может работать. Заглушки позволяют проверить логику верхнего уровня до реализации следующего уровня.

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

1.4. Основания и история объектно-ориентированного подхода к программированию

Объектно-ориентированное программирование появилось и по­лучило широкое распространение ввиду осознания трех важнейших проблем программирования.

1 - раз­витие языков и методов программирования не успева­ло за растущими потребностями в про­граммах. Единственным реальным способом удовлетворить эти потребности был метод многократ­ного использования уже разработанного, протестированного и отлаженного программного обеспечения.

2 - необходимость упрощения сопровождения и модификации разра­ботанных систем. (Факт постоянного изменения требований к системе был осознан как нормальное условие развития системы, а не как неумение или недостаточно четкая организация работы разра­ботчиков.) Требовалось изменить способ построения программных систем так, чтобы локальные модификации не нарушали работоспособность всей системы и было легче производить изменения поведения системы.

3 - это облегчение проектирования систем. Далеко не все задачи поддаются алгоритмическому описанию и тем более алгоритмической декомпозиции, как того требует структур­ное программирование. Требовалось приблизить структуру программ к структуре решаемых задач и сократить так называемый семантический разрыв между структурой решаемой задачи и структурой программы. Семантический разрыв имеет место в том случае, когда понятия, лежащие в основе языка задачи и средств ее реше­ния, различны. Поэтому наряду с необходимостью записи самого решения требуется еще перевести одни понятия в другие. (Сравните это с переводом с одного естественного языка на другой. Именно потому, что таких понятий в русском языке раньше не было, появляются слова типа брокер, оффшор или инвестор. К сожалению, в программировании заимствование слов невозможно.)

Итак, упрощение проектирования, ускорение разработки за счет многократного использования готовых модулей и легкость модифика­ции - вот три основных достоинства объектно-ориентированного программирования, которые пропагандировались его сторонниками.

Объектно-ориентированное программирование предполагает единый подход к проектированию, построению и развитию системы.

Появление объектно-ориентированного метода произошло на основе всего предыдущего развития методов разработки программного обеспечения, а также многих других отраслей науки.

Возникновению объектно-ориентированного подхода к проектированию систем способствовали следующие достижения технологии:

1 - Развитие вычислительной техники, в частности аппаратная поддержка основных концепций операционных систем и построение функционально-ориентированных систем.

2 - Достижения в методологии программирования, в частности модульное построение систем и инкапсуляция информации.

3 - Теория построения и моделирования систем управления базами данных внесла в объектное программирование идеи построения отношений между объектами.

4 - Исследования в области искусственного интеллекта позволили лучше осознать механизмы абстракции. Теория фреймов, предложенная Минским для представления реальных объектов в системах распознавания образов, дала мощный импульс не только системам искусственного интеллекта, но и механизмам абстракции в языках программирования.

5 - Развитие философии и теории познания. Во многом объектно-ориентированное построение систем - это определенный взгляд на моделируемый реальный мир. Именно в этом аспекте философия и теория познания оказали сильное влияние на объектную модель. Еще древние греки рассматривали мир в виде объектов или процессов. Декарт выдвинул предположение, что для человека естественным представляется объектно-ориентированное рассмотрение окружающего мира. Минский предположил, что разум прояв­ляется как взаимодействие агентов, не умеющих по отдельности мыслить.

Объектно-ориентированный подход к программированию поддерживается языками программирования, такими, как Смолток, Си++, Java и т.д. Языки являются главными инструмента­ми объектно-ориентированного программирования, именно при их разработке появилось большинство тех идей, которые и со­ставляют основу объектно-ориентированного метода.

Первым шагом на пути создания объек­тной модели следует считать появление абстрактных типов дан­ных. Считается, что первой полной реализацией абстрактных ти­пов данных в языках программирования является язык Симула.

Затем появились (и продолжают появляться) другие объектно-ориентированные языки, которые определяют современное состоя­ние программирования. Наиболее распространенными из них стали Си++, CLOS, Эйффель, Java.

Эту статью я подготовил во время дискуссий по поводу паттерна Мост, но тогда не опубликовал. Думал разобрались, так как было упомянута Domain Driven Design , и казалось, что необходимость проектирования и программирования именно в стиле ООП никем не оспариваются. Но все же со временем я столкнулся с непониманием. Это будет чисто историческая теоретическая статья. Конечно, даже без попытки обхвата всей широты темы. Но это так сказать посыл молодому разработчику, который читает по верхам и не может выбрать каких принципов и правил ему придерживаться, что первично, а что вторично.

Заглавие этой темы для многих сейчас может показать очень спорным (и скорее намерено провокационным, но для дела:)). Но все же мы постараемся это здесь обосновать и понять какими свойствами должна обладать парадигма программирования, чтобы иметь право называться парадигмой.

Единственно прошу, если прочитали по диагонали - комментируйте сдержано.

Что нам говорит Флойд о парадигмах?

Термин «парадигма программирования» ввел Роберт Флойд (""R. W. Floyd."" ""Communications of the ACM"", 22(8):455-460, 1979. Русский перевод см. в кн.: Лекции лауреатов премии Тьюринга за первые двадцать лет (1966-1985), М.: МИР, 1993.). Он в своей лекции в 1979 году говорит о следующем:

Знакомый пример парадигмы программирования - это структурное программирование, которая, кажется, доминирующей парадигмой в методологии программирования. Она разделяется на две фазы. В первой фазе, нисходящего проектирования, проблема разделяется на небольшое количество более простых подпроблем. Это постепенное иерархическое разложение продолжается пока возникнет выделенные подпроблемы, которые достаточно просты, чтобы с ними справиться непосредственно. Вторая фаза парадигмы структурного программирования влечет за собой работу вверх от конкретных объектов и функций к более абстрактным объектам и функциям, используемые всюду в модулях, произведенных нисходящим проектированием. Но парадигма структурного программирования не универсальна. Даже её самые ярые защитники признали бы, что её отдельно недостаточно, чтобы сделать все сложные проблемы легкими. Другие парадигмы высокого уровня более специализированного типа продолжают быть важными. (Это не точный перевод, а авторская компиляция на основе лекции Р. Флойда, но максимально придерживаясь его слов. Формулировки изменены и скомпонованы лишь для выделения основной мысли Р.Флойда и понятного его изложения.)

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

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

Особенности парадигм более высокого уровня

Как мы видим Р. Флойд тоже различал парадигмы на более высокоуровневые, и более специализированные. Какие же особенности парадигм позволяют говорить, что они более высокоуровневые? Конечно, это возможность их применения к различным предметным задачам. Но что делает парадигмы, применимым к различным предметным задачам? Конечно, вопрос тут не в особенностях предметной задачи, которую можно решить тем или иным подходом. Все парадигмы, которые предлагают создавать алгоритмы тем или иным специализированным способом - вовсе не являются парадигмами, это лишь особый подход в рамках парадигмы более высокого уровня.

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

Но возвратимся к нашему вопросу: что делает парадигмы, применимым к различным предметным задачам? Но чтобы на него ответить нам нужно сделать исторический экскурс.

Основы парадигмы структурного программирования

Мы знаем, что идеи о структурном программировании возникли после доклада Э. Дейкстры еще в 1965 году, где он обосновал отказ от оператора GOTO. Именно этот оператор превращал программы в неструктурированные (Спагетти-код), а Дейкстра доказал, что возможно написать программы без использования этого оператора в результате чего программы станут структурными.

Но одно дело теория, а другое практика. В этом смысле, представляет интерес рассмотреть, какая ситуация была к 1975 году. Это хорошо видно по книге Э. Йодана (). Рассмотреть это важно потому, что сейчас спустя более 30 лет, принципы уже хорошо известные тогда, сейчас переоткрываются, и возводятся в новый ранг. Но при этом теряется исторический контекст, и иерархия важности этих принципов, что первично, а что вторично. Эта ситуация аморфности очень хорошо характеризует сегодняшнее состояние программирования.

Но что было тогда? Как описывает Йодан, все начинается с ответа на вопрос: «Что значит написать хорошую программу?». Вот первый критерий, на какие вопросы должна отвечать парадигма программирования высокого уровня. Если она не отвечает прямо на этот вопрос, а рассказывает вам как можно получить некоторые интересные характеристики вашей программы, то вы имеете дело с парадигмой низкого уровня - подходом при программировании.

На заре зарождения программирования, существовал такой подход к оценке программистов по скорости написания программ. А значит ли это, что он пишет хорошие программы? Пользуется ли он особым расположением и уважением руководства? Если ответ на последний вопрос утвердительный, то все вопросы совершенствования программирования представляют скорее академический интерес. Но руководство может также заметить, что некоторые суперпрограммисты могут делать программы очень быстро или писать очень эффективные программы, но эти программы иногда остаются неоформленными, их невозможно понять, сопровождать или модифицировать. А на последние тоже не мало тратится времени.

Примечателен, довольно характерный спор программистов:
* Программист А: “Моя программа в десять раз быстрее вашей, и она занимает в три раза меньше памяти!”
* Программист Б: “Да, но ваша программа не работает, а моя - работает!”

Но программы постоянно усложняются и поэтому нам недостаточно того, что программа просто работает. Нужны определенные методы верификации правильности работы программы и самого программиста. Причем это не тестирование программы, а проведение некоторой систематической процедуры проверки именно правильности программы в смысле её внутренней организации. То есть уже тогда, говоря современным языком, говорили о ревизии кода (Code review).

Кроме того, уже тогда говорили о гибкости программы - о простоте ее изменения, расширения и модификации. Для этого необходимо постоянно отвечать на вопросы определенного вида. “Что будет, если мы захотим расширить эту таблицу?”, “Что произойдет, если однажды мы захотим определить новую программу изменений?”, “А что, если нам придется изменить формат таких-то выходных данных?”, “Что будет, если кто-то решит вводить данные в программу другим способом?”.

Также говорили о важности спецификаций интерфейсов, т.е. формализованный подход к спецификации входов, функций и выходов, которые должны быть реализованы каждым модулем.

Кроме того, центральное внимание уделяли размеру и неизменности модуля. Причем что касается неизменности модуля, то она рассматривалась не целиком, а с выделением отдельных факторов:
1. Логическая структура программы, т.е. алгоритм. Если вся программа зависит от некоторого специального подхода, то в скольких модулях потребуется внести изменения при изменении алгоритма?
2. Аргументы, или параметры, модуля. Т.е. изменение спецификации интерфейсов.
3. Внутренние переменные таблиц и константы. Многие модули зависят от общих таблиц, если изменяется структура таких таблиц, то мы можем ожидать, что модули также изменятся.
4. Структура и формат базы данных. В большей степени эта зависимость аналогична зависимости от общих переменных и таблиц, упомянутой выше, с той разницей, что с практической точки зрения базу данных удобнее считать независимой от программы.
5. Модульная структура управления программой. Некоторые пишут модуль не особенно задумываясь над тем, каким образом он будет использоваться. Но если изменились требования. Какую часть логической структуры модуля нам придется изменить?

Эти и множество других аспектов (которые мы тут не рассмотрели) в целом и формулируют представление о структурном программировании. Забота об этих аспектах и делает структурное программирование парадигмой высокого уровня.

Основы парадигмы объектно-ориентированного программирования

Как мы могли видеть все принципы организации хороших программ рассматриваются в структурном программировании. Появление еще одного или группы неизвестных до этого принципов написания хороших программ могло бы изменить парадигму? Нет. Это всего лишь расширило бы способы и идеологию написания структурированных программ, т.е. парадигму структурного программирования.

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

Уже признано, что причиной появления объектно-ориентированной парадигмы стала необходимость писать все более и более сложные программы, в то время как парадигма структурного программирования имеет некий предел, после которого развивать программу становится невыносимо сложно. Вот, например, что пишет Г. Шилдт:

На каждом этапе развития программирования появлялись методы и инструментальные средства для “обуздания” растущей сложности программ. И на каждом таком этапе новый подход вбирал в себя все самое лучшее из предыдущих, знаменуя собой прогресс в программировании. Это же можно сказать и об ООП. До ООП многие проекты достигали (а иногда и превышали) предел, за которым структурный подход к программированию оказывался уже неработоспособным. Поэтому для преодоления трудностей, связанных с усложнением программ, и возникла потребность в ООП. ()

Чтобы понять причину, почему именно объектно-ориентированное программирование, позволило писать более сложные программы и практически убрать проблему возникновения предела сложности, обратимся к одному из основоположников ООП - Гради Бучу (). Свое объяснение ООП он начинает с того, что значит сложность и какие системы можно считать сложными. То есть целенаправленно подходит к вопросу написания сложных программ. Далее переходит к вопросу связи сложности и человеческих возможностей понять эту сложность:

Существует еще одна главная проблема: физическая ограниченность возможностей человека при работе со сложными системами. Когда мы начинаем анализировать сложную программную систему, в ней обнаруживается много составных частей, которые взаимодействуют друг с другом различными способами, причем ни сами части системы, ни способы их взаимодействия не обнаруживают никакого сходства. Это пример неорганизованной сложности. Когда мы начинаем организовывать систему в процессе ее проектирования, необходимо думать сразу о многом. К сожалению, один человек не может следить за всем этим одновременно. Эксперименты психологов, например Миллера, показывают, что максимальное количество структурных единиц информации, за которыми человеческий мозг может одновременно следить, приблизительно равно семи плюс-минус два. Таким образом, мы оказались перед серьезной дилеммой. """Сложность программных систем возрастает, но способность нашего мозга справиться с этой сложностью ограничена. Как же нам выйти из создававшегося затруднительного положения?"""

Затем он говорит о декомпозиции:

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

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

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

Теперь, если посмотреть внимательнее, оказывается, что объектно-ориентированная парадигма есть не что иное как моделирование вообще, наиглавнейший аспект которого наиболее четко выразил С. Лем:

Моделирование - это подражание Природе, учитывающее немногие ее свойства. Почему только немногие? Из-за нашего неумения? Нет. Прежде всего потому, что мы должны защититься от избытка информации. Такой избыток, правда, может означать и ее недоступность. Художник пишет картины, но, хотя мы могли бы с ним поговорить, мы не узнаем, как он создает свои произведения. О том, что происходит в его мозгу, когда он пишет картину, ему самому неизвестно. Информация об этом находится в его голове, но нам она недоступна. Моделируя, следует упрощать: машина, которая может написать весьма скромную картину, рассказала бы нам о материальных, то есть мозговых, основах живописи больше, чем такая совершенная «модель» художника, какой является его брат-близнец. Практика моделирования предполагает учет некоторых переменных и отказ от других. Модель и оригинал были бы тождественны, если бы процессы, происходящие в них, совпадали. Этого не происходит. Результаты развития модели отличаются от действительного развития. На это различие могут влиять три фактора: упрощенность модели по сравнению с оригиналом, свойства модели, чуждые оригиналу, и, наконец, неопределенность самого оригинала. (фрагмент произведения «Сумма технологий», Станислав Лем, 1967)

Таким образом, С. Лем говорит о абстрагировании как основе моделирования. В тоже время абстрагирование и есть главный признак объектно-ориентированной парадигмы. Г. Буч по этому поводу пишет:

Разумная классификация, несомненно, - часть любой науки. Михальски и Степп утверждают: «неотъемлемой задачей науки является построение содержательной классификации наблюдаемых объектов или ситуаций. Такая классификация существенно облегчает понимание основной проблемы и дальнейшее развитие научной теории». Почему же классификация так сложна? Мы объясняем это отсутствием «совершенной» классификации, хотя, естественно, одни классификации лучше других. Кумбс, Раффья и Трал утверждают, что «существует столько способов деления мира на объектные системы, сколько ученых принимается за эту задачу». Любая классификация зависит от точки зрения субъекта. Флуд и Кэрсон приводят пример: «Соединенное Королевство… экономисты могут рассматривать как экономический институт, социологи - как общество, защитники окружающей среды - как гибнущий уголок природы, американские туристы - как достопримечательность, советские руководители - как военную угрозу, наконец, наиболее романтичные из нас, британцев - как зеленые луга родины».

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

Как мы уже отмечали, определение ключевых абстракций включает в себя два процесса: открытие и изобретение. Мы открываем абстракции, слушая специалистов по предметной области: если эксперт про нее говорит, то эта абстракция обычно действительно важна. Изобретая, мы создаем новые классы и объекты, не обязательно являющиеся частью предметной области, но полезные при проектировании или реализации системы. Например, пользователь банкомата говорит «счет, снять, положить»; эти термины - часть словаря предметной области. Разработчик системы использует их, но добавляет свои, такие, как база данных, диспетчер экрана, список, очередь и так далее. Эти ключевые абстракции созданы уже не предметной областью, а проектированием.

Наиболее мощный способ выделения ключевых абстракций - сводить задачу к уже известным классам и объектам.

Итак, объектно-ориентированная парадигма становится парадигмой высокого уровня, и главенствует над принципами парадигмы структурного программирования, так как занимается моделированием реальности, строит модели предметных областей на языке специалистов этих областей. Если Вы этим пренебрежете ради написания хорошей программы, которую станет легко модифицировать, расширять, в которой будут четкие интерфейсы и независимые модули, вы возвратитесь на уровень парадигмы структурного программирования. Ваша программа будет всем хороша, но её нельзя будет понять, так как она не будет соответствовать реальности, она будет объяснена в терминах только известных вам, а специалист знающий предметную область не сможет без вашей помощи разобраться в программе. В конце концов, сложность будет понижаться в очень узком диапазоне, хотя вы и организовали хорошую программу. Но именно программу, а не модель. Отсутствие модели, или лишь её поверхностное представление, «взорвет» вашу хорошую программу изнутри, и не даст дальше развивать и сопровождать её в дальнейшем. Когда вы вводите классы, абстракций которых не существует, когда эти классы чисто системные и не имеют ничего общего с предметной областью, когда они введены лишь для упрощения потоков взаимодействия других классов - ваше программное обеспечение становится «с бородой», и если путем рефакторинга не следить за такими участками в один прекрасный момент развитие вашего ПО остановится, и станет не возможным - вы достигните предела структурного программирования (а вам казалось, используя классы и объекты вам это не грозит?).

upd. Я тут подумал, тема острая, я комментировать не буду. Факты я изложил в статье, а скатываться на уровень холивара не хочу. Если это не помогло задуматься - ну, что ж значит не повезло в этот раз. Действительно, будет конструктивно - если напишите контрдоводы в отдельной статье. Я же не берусь разрушать массовые стереотипы.

Да, и еще, чтобы было понятно - опубликовать я решил после дискуссий здесь Запрограммируем перцептрон Розенблатта? , где очевидным образом стало понятно, что функциональное программирование при построении плохой модели в ООП работает хуже не куда. И то, что они хвалятся супер скоростью - это фикция, на самом деле важна правильная модель. Для некоторых (не много таких задач сравнительно) функциональное программирование может быть успешным, но его не нужно использовать повсеместно, там где оно не дает ничего хорошего. Ну, или так - сможете написать обсуждаемый там кусок ТОЛЬКО в функциональном стиле, и чтобы это работало быстрее, чем с событиями ООП?

Лекция 1. Объектно-ориентированное программирование.

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

8.1. Структурный подход в программировании.

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

Другими факторами, влияющими на эволюцию методов проектирования и создания ПП, являются:

Изменение архитектур вычислительных средств (ВС) в интересах повышения
производительности, надежности;

Упрощение взаимодействия пользователей с ВС и интеллектуализация ВС.
Действие двух последних факторов сопряжено с ростом сложности программного обеспечения ВС. Сложность представляет неотъемлемое свойство программирования и программ, которое проявляется во времени и стоимости создания программ, в объеме или длине текста программы, характеристиках ее логической структуры, задаваемой операторами передачи управления (ветвления, циклы, вызовы подпрограмм).

Выделяют 5-ть источников сложности программирования:

Решаемая задача;

Язык программирования;

Среда выполнения программы;

Технологический процесс коллективной разработки и создания ПП;

Стремление к универсальности и эффективности алгоритмов и типов данных.

От свойства сложности нельзя избавиться, но можно изменять характеристики его проявления путем управления или организации.

В программировании широко используется фундаментальный принцип управления сложными системами, который известен человеку с глубокой древности - devide et impera (разделяй и властвуй, лат.) и применяется при разработке и проектировании любых сложных технических систем. Согласно первой части этого принципа, при проектировании сложной программной системы проводится алгоритмическая декомпозиция решаемой задачи.

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

Наряду с термином декомпозиция , также используется термин структуризация проблемы, задачи или программы. Идеи разделения программ на относительно самостоятельные крупные части, реализующие определенные процедуры и функции и образующие определенную иерархию взаимосвязей, нашли отражение в структурном подходе к разработке и созданию программных средств. В программировании структурный подход появился с возникновением первых подпрограмм и функций, написанных в процедурно-ориентированном стиле. Данный стиль опирается на правило: определить переменные и константы, которые понадобится хранить в памяти компьютера и описать алгоритм их обработки.

Теоретическое оформление структурный подход получил в начале 70-х годов в работах теоретиков и практиков программирования(А.П.Ершова, Э. Йодана, Н.Вирта). Следует отметить появление структурного программирования, в котором нашла определенное отражение идея упорядочивания структуры программы. Структурное программирование ориентирует на составление программ, структура которых близка к «дереву» операторов или блоков. Использование структуры типа «дерево» в качестве своеобразного эталона объясняется тем, что это простая для анализа и реализации структура.

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

Важнейшими инструментами производителей ПП, в которых находят отражение практически все аспекты эволюции, являются языки программирования .

Язык программирования изначально ориентирован на компьютер и содержит набор типов данных, операторов, операций, функций, которые достаточно просто могут быть переведены в команды по управлению аппаратным и программным обеспечением компьютера. При этом желательно максимизировать эффективность трансляции предложений языка в машинные коды в смысле минимизации требуемой памяти, времени выполнения программы и стоимости создания транслятора. Вместе с тем язык программирования ориентирован на программиста и предоставляет средства для моделирования объектов, их свойств и поведения при решении прикладных задач в некоторой предметной области в виде программ.

Развитие языков в направлении повышения эффективности составления прикладных программ привело к разделению языков по следующим уровням:

Низкий уровень (машинно-ориентированные языки - языки ассемблера),

Высокий уровень (процедурно-ориентированные языки: FORTRAN , ALGOL ,

PL /1, Pascal ),

Уровень решаемой задачи (проблемно-ориентированные языки - SQL ).

Введение типов данных обозначило еще одно направление развития технологии программирования. Типизация данных предназначена как для облегчения составления программ, так и для автоматизации выявления ошибок использования данных в виде операндов и фактических параметров при вызове функций.

Использование структурных типов данных позволяет, во-первых, упростить работу алгоритмиста при сопоставлении структур данных прикладной задачи и данных, обрабатываемых функциями программных модулей, и, во-вторых, сократить объем рутинной работы программиста при кодировании алгоритма обработки.

Результатом обобщения понятия «тип данных» являются классы объектов (C++), которые могут содержать в качестве элементов не только данные определенного типа, но и методы их обработки (функции).

Таким образом, по мере развития технологии программирования и в программах, и в типах данных все адекватнее отражалась структура решаемой прикладной задачи и осуществлялась соответствующая интеграция данных и программ в модулях. Одновременно с этим языки программирования пополнились средствами , необходимыми для описания подобных структур. Развитие идей абстрагирования и модульности привело к появлению в программировании объектного подхода .

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

Язык программирования позволяет описать свойства моделируемых объектов и порядок манипуляции с объектами или порядок их взаимодействия, сообразуясь с условиями решаемой задачи. Первые языки программирования ориентировались на математические объекты, на определенную модель вычислителя. Поэтому они содержали такие конструкции как переменная, константа, функция, формальные и фактические параметры. Программисты представляли свои программы в виде взаимодействующих функций и модулей. Характер программирования был процедурно-ориентированным, поскольку первостепенное внимание уделялось последовательностям действий с данными. Соответственно такие языки программирования, как FORTRAN , PL -1, С называют процедурно-ориентированными.

Данные и подпрограммы объединялись в модули в соответствии с логикой проектировщиков, создающих сложные программные системы для определенных областей их применения. Логика интеграции в модули определялась рядом факторов, среди которых следует отметить свойства предметной области : данные и подпрограммы их обработки, соответствующие определенному классу объектов предметной области, объединялись в модуль. Так, модуль обработки строк содержал функции выполнения основных операций со строками: объединения, сравнения, копирования, вычисления длины строки.

Развитием идеи модульного программирования является сопоставление объектам предметной области (моделируемым объектам) программных конструкций, называемых объектами, объектными типами или классами (моделирующими объектами). Моделирующие объекты содержат данные и функции, которые описывают свойства моделируемых объектов. Так, данные могут отражать признаковые или количественные свойства (масса, длина, мощность, цена), а функции отражают поведенческие или операционные свойства (изменить массу, вычислить мощность, установить цену). Таким образом, при объектном подходе интеграция данных и функций их обработки определяется структурой предметной области, т.е набором моделируемых объектов, их взаимодействием в рамках решаемой задачи.

Моделируемый объект всегда представляется человеку чем-то единым, целостным, хотя может состоять из частей или других объектов. Целостное представление объекта в виде взаимосвязанной совокупности его свойств или компонентов является базовым принципом объектного подхода.

Объектный подход начал развиваться в программировании с 70-х годов ( Smalltalk , CLOS , Ada ). Эти языки называются объектными . Иерархическая классификация объектов и наследование свойств являются отправными идеями появившегося в 80-х годах объектно-ориентированного подхода. Одной из причин сравнительно медленного становления объектно-ориентированного стиля программирования является его существенное отличие от процедурно-ориентированного стиля.

8.2. Концепции объектно-ориентированного программирования.

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

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

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

Инкапсуляции;

Наследования;

Полиморфизма.

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

Объекты и классы.

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

Класс объектов представляет собой программную структуру, в которой данные и функции образуют единое целое и отражают свойства и поведение этого целого в рамках моделируемой предметной области. В отличие от модуля, в котором на состав данных и функций накладывается меньше смысловых ограничений, в объекте присутствуют только те данные и функции, которые необходимы для описания свойств и поведения объекта определенного типа.

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

Так, на основе анализа авиационной техники можно выделить класс объектов Самолет. При этом мы абстрагировались от таких свойств как: форма крыльев, длина флюзеляжа, используемые материалы конструкций, расположение крыльев. К числу основных свойств класса объектов Самолет можно отнести: скорость полета, размах крыльев, тип двигателя, грузоподъемность, высота полета, функциональное назначение.

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

Инкапсуляция свойств объектов.

Инкапсуляция («содержание в оболочке») представляет собой объединение и локализацию в рамках объекта, как единого целого, данных и функций, обрабатывающих эти данные. В совокупности они отражают свойства объекта.

В C++ данные класса и объекта называются элементами данных или полями, а функции — методами или элементами-функциями.

Доступ к полям и методам объекта осуществляется через имя объекта и соответствующие имена полей и методов при помощи операций выбора «.» и «->». Это позволяет в максимальной степени изолировать содержание объекта от внешнего окружения, т. е. ограничить и наглядно контролировать доступ к элементам объекта. В результате замена или модификация полей и методов, инкапсулированных в объект, как правило, не влечет за собой плохо контролируемых последствий для программы в целом. При необходимости указания имени объекта в теле описания этого объекта в C++ используется зарезервированное слово this , которое в рамках объекта является специальным синонимом имени объекта - указателем на объект.

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

Можно сказать, что инкапсуляция подразумевает под собой скрытие данных ( data hiding ), что позволяет защитить эти данные.

А теперь определение, которое точно определяет суть инкапсуляции:

Переменные состояния объекта скрыты от внешнего мира. Изменение состояния объекта(его переменных) возможно ТОЛЬКО с помощью его методов(операций).

Почему же это так важно? Этот принцип позволяет защитить переменные состояния объекта от неправильного их использования.

Это существенно ограничивает возможность введения объекта в недопустимое состояние и несанкционированное разрушение этого объекта.

Для иллюстрации приведенного выше постулата рассмотрим пример.

Представьте, что у Вас не заводится машина и Вы, увы, не механик и плохо разбираетесь в машинах. Вы открываете капот и начинаете выдергивать какие-то шланги, что-то окручивать и т.д. Хорошо, если Вы запомнили что, где и как выдергивали и откручивали. А если нет? Или у Вас стрелка уровня топлива стоит на нуле, а Вы считаете, что у Вас полно топлива и полезете со спичками внутрь бензобака проверять уровень топлива. Какие последствия Вас могут ожидать? В лучшем случае Вы и Ваша машина останутся живы, если Вам очень повезет. Аналогично и с нашими объектами, которые могут быть чрезвычайно сложными, а Вы пытаетесь что-то в них подправить, не представляя их внутреннюю организацию.

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

Именование классов, элементов данных и методов имеет большое значение в ООП. Названия должны либо совпадать с названиями, использующимися в предметной области, либо ясно отражать смысл или назначение (функциональность) именуемого класса, поля или метода. При этом не следует бояться длинных имен - затраты на написание окупятся при отладке и сопровождении продукта. Текст подобной программы становится понятным без особых комментариев. Дополнительным средством доступа к данным и методам является описание элементов классов с помощью спецификаторов private , protected и public , которые определяют три соответствующих уровня доступа к компонентам класса: частные, защищенный и общедоступный.

Для расширения доступа к элементам данных, имеющим атрибуты private или protected , в классе можно реализовать с атрибутом public специальные методы доступа к собственным и защищенным элементам данных.

Методы в классе могут быть объявлены как дружественные ( friend ) или виртуальные ( virtual ). Иногда встречается объявление перегружаемых ( overload ) функций.

Гибкое разграничение доступа позволяет уменьшить нежелательные (бесконтрольные) искажения свойств объекта или несанкционированное использование свойств классов.

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

Наследование свойств.

Наследование есть свойство классов порождать своих потомков и наследовать свойства (элементы данных и методы) своих родителей. Класс-потомок автоматически наследует от родителя все элементы данных и методы, а также может содержать новые элементы данных и методы и даже заменять (перекрывать, переопределять) методы родителя или модифицировать (дополнять) их.

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

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

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

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

Наследование в ООП позволяет адекватно отражать родственные отношения объектов предметной области. Если класс В обладает всеми свойствами класса А и еще имеет дополнительные свойства, то класс А называется базовым (родительским), а класс В называется наследником класса А. В C++ возможно одиночное (с одним родителем) и множественное (с несколькими родителями) наследование.

Родственные отношения или отношения включения свойств классов, могут отражаться не только с помощью наследования, но и путем инкапсуляции в классе в качестве элементов данных других классов.

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

Базовые классы или корни подобных деревьев, обладают такими абстрактными свойствами, что часто непосредственно в программах не используются, а необходимы «всего лишь» для порождения требуемых классов. Правильный выбор корня обеспечивает удобство « выращивания » дерева, т. е. простоту развития библиотеки классов Применение правила ООП «наследуй и изменяй свойства объектов» хорошо согласуется с поэтапным подходом к разработке и созданию больших программных систем.

Примеры родственных классов: Координаты на экране -> Цветная точка -> Прямая -> Прямоугольник. Здесь направление стрелки указывает порядок наследования свойств классов.

При указании базового (родительского) класса в описании класса в С++ требуется указать ключевое слово public . Указание этого ключевого слова позволит получить свободный доступ ко всем методам класса, как если бы они были описаны в самом производном классе. В противном же случае, мы не сможем получить доступ к методам родительского класса.

Пример описания наследования классов на С++ :

class A

. . . . .

class B: public A

. . . . .

Полиморфизм поведенческих свойств объектов.

Слово полиморфизм имеет греческое происхождение и переводится как "имеющий много форм".

Полиморфизм - это свойство, которое позволяет одно и тоже имя использовать для решения нескольких технически разных задач.

В общем смысле, концепцией полиморфизма является идея "один интерфейс, множество методов". Это означает, что можно создать общий интерфейс для группы близких по смыслу действий. Преимуществом полиморфизма является то, что он помогает снижать сложность программ, разрешая использование одного интерфейса для единого класса действий. Выбор конкретного действия, в зависимости от ситуации, возлагается на компилятор.

Применительно к ООП, целью полиморфизма, является использование одного имени для задания общих для класса действий. На практике это означает способность объектов выбирать внутреннюю процедуру (метод) исходя из типа данных, принятых в сообщении.

Представьте, что нужно открыть замок и есть связка ключей. И вот мы пытаемся его открыть. Мы имеем связку ключей, у каждого из которых есть какие-то параметры (форма, размер). Для того, чтобы открыть дверь мы перебираем один ключ за другим пока не найдем подходящий. Т.е. когда шаблон замка совпадает с шаблоном параметров ключа, замок открывается. Аналогично работает компилятор при наличии нескольких функций. Он последовательно проверяет шаблоны функций с одним и тем же именем пока не найдет подходящий.

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

Свойство полиморфизма реализуется не только в механизме замещения (перекрытия) одноименных методов при наследовании свойств, но и в механизме виртуализации методов или позднем связывании методов. Если замещение метода реализуется на этапе компиляции (раннее связывание объекта с методом), то замещение объявленного в описании класса виртуальным ( virtual ) происходит на этапе выполнения (позднее связывание).

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

Приведенный пример в определенной мере отражает смысл применения раннего и позднего связывания, соответственно. Очевидно, что для данного примера первый вариант оптимален. Во втором случае мы слишком много всего предусмотрели, но нам это не понадобилось. С другой стороны, если по дороге на рынок мы решим, что апельсины нам не нужны и решим купить 10 кг яблок, то в первом случае мы уже не сможем этого сделать. Во втором же случае - легко.

А теперь рассмотрим этот пример с точки зрения программирования. При применении раннего связывания, мы как бы говорим компилятору: "Я точно знаю, чего я хочу. Поэтому жестко(статически) связывай все вызовы функций". При применении механизма позднего связывания мы как бы говорим компилятору: "Я пока не знаю чего я хочу. Когда придет время, я сообщу что и как я хочу". Таким образом, во время раннего связывания вызывающий и вызываемый методы связываются при первом удобном случае, обычно при компиляции. При позднем связывании вызываемого метода и вызывающего метода они не могут быть связаны во время компиляции. Поэтому реализован специальный механизм, который определяет как будет происходить связывание вызываемого и вызывающего методов, когда вызов будет сделан фактически.

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

Виртуальные методы выполняются медленнее, из-за необходимости дополнительных действий по связыванию.

Создание и уничтожение объектов.

Описание класса в ООП есть некоторая программная структура, которую используют при создании объектов, отличающихся именами и отдельными свойствами. Создание и удаление объектов осуществляется с помощью специальных методов, которые называются конструкторами (constructor ) и деструкторами (destructor ) соответственно.

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

Взаимодействие объектов и сообщения.

Отношение родства или включения свойств - это только один из многих типов отношений между классами. Еще одним важнейшим типом отношений между классами и между объектами являются отношения взаимодействия или отношения «клиент-сервер». Отношения родства также подразумевают определенное отношение взаимодействия, ограниченное свойством инкапсуляции.

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

Часто связь устанавливают при помощи указателей, что делает программу похожей на структуру данных в динамической памяти. Основным содержанием программы являются описание классов и совокупности взаимодействующих объектов. В библиотеках классов для доступа объекта к самому себе (внутри себя) используется зарезервированное слово this , являющееся синонимом имени объекта, в контексте которого оно используется.

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

8.3. Этапы объектно-ориентированного программирования.

Программа, решающая некоторую задачу, заключает в себе описание части мира, относящегося к этой задаче или определенной предметной области. Описание действительности в форме взаимодействующих объектов, по-видимому, естественнее, чем в форме иерархии подпрограмм, и поэтому облегчает программное моделирование в некоторой предметной области.

В процессе программирования в объектно-ориентированном стиле можно выделить следующие этапы:

1. Определение основных понятий предметной области и соответствующих им классов, имеющих определенные свойства (возможные состояния и действия). Обоснование вариантов создания объектов.
2. Определение или формулирование принципов взаимодействия классов и взаимодействия объектов в рамках программной системы.
3. Установление иерархии взаимосвязи свойств родственных классов.
4. Реализация иерархии классов с помощью механизмов инкапсуляции, наследования и полиморфизма.
5. Для каждого класса реализация полного набора методов для управления свойствами объектов.

В результате будет создана объектно-ориентированная среда или библиотека классов, позволяющая решать задачи моделирования в определенной предметной области.

Первые три этапа и являются объектно-ориентированным анализом предметной области.

ООП обладает следующими достоинствами :

Использование более естественных понятий и имен из повседневной жизни или предметной области;

Простота введения новых понятий на основе старых;

Отображение в библиотеке классов наиболее общих свойств и отношений между объектами моделируемой предметной области;

Естественность отображения пространства решаемой задачи в пространство объектов программы;

Простота внесения изменений в классы, объекты и программу в целом;

Полиморфизм классов упрощает составление и понимание программ;

Локализация свойств и поведения на основе инкапсуляции и разграничения доступа упрощают понимание структуры программы и ее отладку;

Передача параметров в конструкторах объектов повышает гибкость создаваемых программных систем.

В качестве недостатков ООП можно отметить следующие:

Снижение быстродействия программ, особенно при использовании виртуальных методов;

Большие затраты времени на разработку библиотеки классов, поэтому ООП це-лесообразно при создании больших программ, а не при написании маленьких единичных программ;

Необходимость анализа полной иерархии классов для правильного использования свойств базовых классов.

Целесообразность применения технологии ООП для создания конкретной программной системы определяется двумя главными факторами :

Спецификой предметной области и решаемой прикладной задачи;

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

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

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