Справочник врача 21

Поиск по медицинской литературе


Абстракция ооп




Объектно-ориентированное программирование является лишь последним звеном в длинной цепи решений, которые были предложены для разрешения «кризиса программного обеспечения». Положа руку на сердце: кризис программного обеспечения просто означает, что наше воображение и те задачи, которые мы хотим решить с помощью компьютеров, почти всегда опережают наши возможности. Несмотря на то что объектно-ориентированное программирование действительно помогает при создании сложных программных систем, важно помнить, что ООП не является «серебряной пулей» (термин, ставший популярным благодаря Фреду Бруксу [Brooks 1987]), которая запросто справляется с чудовищем. Программирование попрежнему является одной из наиболее трудных задач, взваливаемых на себя человеком. Чтобы стать профессионалом в программировании, необходимы талант, способность к творчеству, интеллект, знания, логика, умение строить и использовать абстракции и, самое главное, опыт — даже в том случае, когда используются лучшие средства разработки. Я подозреваю, что есть и другая причина особой популярности таких языков программирования, как C++ и Object Pascal (по контрасту со Smalltalk и Beta). Она состоит в том, что и администрация и разработчики надеются, что программист на языках C или Pascal может перейти на C++ или Object Pascal с той же легкостью, с которой происходит добавление нескольких букв на титульный лист сертификата о специальности. К сожалению, так происходит не всегда. Объектно-ориентированное программирование является новым пониманием того, что собственно называется вычислениями, а также того, как мы можем структурировать информацию внутри компьютера. Чтобы стать профессионалом в технике ООП, требуется полная переоценка привычных методов разработки программ. [стр. 4 ⇒]

2.2. Применение наследования Абсолютно другим механизмом многократного использования кода в ООП является наследование. С его помощью новый класс может быть объявлен как подкласс, или дочерний класс, существующего класса. В этом случае все области данных и функции, связанные с исходным классом, автоматически переносятся на новую абстракцию данных. Новый класс может определять дополнительные значения или функции. Он переопределяет некоторые функции исходного класса, просто объявив новые с такими же именами, как и в исходном классе. Все это проиллюстрировано ниже в классе, который реализует другую версию абстракции Set. Упоминая класс List в заголовке класса, мы показываем, что наша абстракция Set является расширением или уточнением существующего класса List. Таким образом, операции, связанные со списками, применимы и к множествам: Class Set : public List { public: // конструктор Set(); // операции void add (int); int size (); };... [стр. 136 ⇒]

Объектно-ориентированное программирование: а медна пуля не подойдет? Разработка из больших частей. Если осуществлять сборку из частей, которые достаточно сложны и имеют однородные интерфейсы, можно быстро образовывать довольно богатые структуры. Согласно одному из взглядов на объектно-ориентированное программирование эта дисциплина осуществляет модульность и чистые интерфейсы. Другая точка зрения подчеркивает инкапсуляцию — невозможность увидеть и еще менее изменить внутреннюю структуру детали. Еще одна точка зрения отмечает наследование и сопутствующую ему иерархическую структуру классов с виртуальными функциями. И еще один взгляд: важнейшей является сильная абстрактная типизация данных вместе с гарантиями, что конкретный тип данных будет обрабатываться только применимыми к нему операциями. В настоящее время не нужен весь пакет Smalltalk или C++, чтобы использовать любой из этих дисциплин — многие из них поглотили объектно-ориентированные технологии. Объектно-ориентированный подход привлекателен, как поливитамины: одним махом (т.е. переподготовкой программиста) получаешь все. Очень многообещающая концепция. Почему объектно-ориентированная технология медленно развивалась? В течение девяти лет после выхода «СПН» надежды неуклонно росли. Почему развитие было таким медленным? Теорий много. Джеймс Коггинс, в течение четырех лет ведущий колонку в The C++ Report, дает такое объяснение: Проблема в том, что программисты, работающие в ООП, экспериментировали с кровосмесительными приложениями и были нацелены на низкий уровень абстракции. Например, они строили такие классы, как «связанный список» вместо «интерфейс пользователя», или «луч радиации», или «модель из конечных элементов». К несчастью, строгая проверка типов, которая помогает программистам C++ избегать ошибок, одновременно затрудняет построение больших объектов из маленьких.21 Он возвращается к фундаментальной проблеме программирования и доказывает, что один из способов удовлетворить потребность в программном обеспечении — увеличить численность образованной рабочей силы путем подготовки и привлечения наших клиентов. В пользу нисходящего проектирования приводятся такие аргументы: Если мы проектируем крупные классы, представляющие концепции, с которыми наши клиенты уже работают, то они в состоянии понимать и критиковать проект по мере его развития, а также вместе с нами разрабатывать контрольные примеры. Офтальмологов, с которыми я работаю, не волнует организация стека; их волнует описание формы роговицы с помощью полиномов Лежандра. Маленькая инкапсуляция дает и маленькую выгоду. [стр. 122 ⇒]

Я думаю, что Селин совершенно прав: я недооценил как степень настраиваемости пакета, так и важность этого фактора. Объектно-ориентированное программирование: а медная пуля не подойдёт? Разработка из больших частей. Если осуществлять сборку из частей, которые достаточно сложны и имеют однородные интерфейсы, можно быстро образовывать довольно богатые структуры. Согласно одному из взглядов на объектно-ориентированное программирование эта дисциплина осуществляет модульность и чистые интерфейсы. Другая точка зрения подчёркивает инкапсуляцию — невозможность увидеть и ещё менее изменить внутреннюю структуру детали. Ещё одна точка зрения отмечает наследование и сопутствующую ему иерархическую структуру классов с виртуальными функциями. И ещё один взгляд: важнейшей является сильная абстрактная типизация данных вместе с гарантиями, что конкретный тип данных будет обрабатываться только применимыми к нему операциями. В настоящее время не нужен весь пакет Smalltalk или C++, чтобы использовать любой из этих дисциплин — многие из них поглотили объектно-ориентированные технологии. Объектно-ориентированный подход привлекателен, как поливитамины: одним махом (т.е. переподготовкой программиста) получаешь все. Очень многообещающая концепция. Почему объектно-ориентированная технология медленно развивалась? В течение девяти лет после выхода «СПН» надежды неуклонно росли. Почему развитие было таким медленным? Теорий много. Джеймс Коггинс, в течение четырех лет ведущий колонку в The C++ Report , даёт такое объяснение: Проблема в том, что программисты, работающие в ООП, экспериментировали с кровосмесительными приложениями и были нацелены на низкий уровень абстракции. Например, они строили такие классы, как «связанный список » вместо «интерфейс пользователя », или «луч радиации », или «модель из конечных элементов ». К несчастью, строгая проверка типов, которая помогает программистам C++ избегать ошибок, одновременно затрудняет построение больших объектов из маленьких.109 Он возвращается к фундаментальной проблеме программирования и доказывает, что один из способов удовлетворить потребность в программном обеспечении — увеличить численность образованной рабочей силы путём подготовки и привлечения наших клиентов. В пользу нисходящего проектирования приводятся такие аргументы: Если мы проектируем крупные классы, представляющие концепции, с 109 Coggins J. M. Designing C++ libraries // C++ Journal. 1990. Vol. 1, N 1. June. P. 25-32. [стр. 97 ⇒]

Императивная и функциональная парадигмы — два крайних взгляда, две полярных репрезентации дуализма операция–структура. Одну можно назвать инверсией другой. Попыткой синтезировать эти взгляды стала третья парадигма — объектно-ориентированная (ООП). Объектом называется изобретённая в середине 1960-х гг. техническая абстракция, в которой структура и операция объединены в одно целое (или, по крайней мере, которая мыслится как претензия на подобный монизм). В первой публикации об ООП, адресованной широкой аудитории, говорилось: Традиционное представление о программных системах заключается в том, что они состоят из коллекции данных, представляющей какую-то информацию, и набора процедур для манипуляций с этими данными... Проблематичным в этом взгляде на программы как данные/процедуры является то, что с данными и процедурами обращаются так, как если бы они были независимы друг от друга, тогда как в действительности дело обстоит наоборот... Вместо двух типов сущности, представляющих информацию и манипуляцию с ней независимо друг от друга, в объектно-ориентированной системе имеется один-единственный тип сущности, представляющей оба типа.51 Впервые эта абстракция была имплементирована в языках Simula 67 и Smalltalk. Технически объект — это сущность, которая имеет определённые атрибуты и поведение (т.е. включает в себя и структуру, и операцию) и способна взаимодействовать с другими объектами. Принято считать, что ООП ортогональна ИП и ФП, что означает, что две последние могут сочетаться с первой (скажем, более императивный вариант ООП представлен языками С++ и Java, а более функциональный — языком Smalltalk; при этом в императивных и функциональных языках могут использоваться инструменты ООП — например, Objective-C и CLOS соответственно). Практическим мотивом к разработке понятия объекта стало стремление уменьшить сложность репрезентации (complexity management): в результате объединения структуры и операции в одной сущности (так называемая инкапсуляция) скрывается неактуальная информация (information hiding) и разгружается внимание программиста. Теоретическим мотивом стало осознание ограниченности репрезентации функционирования ЭВМ в модусе только структуры или только операции. Создатель термина «объект», соразработчик языка Smalltalk и сотрудник лаборатории Xerox PARC Алан Кэй писал: В компьютерных терминах Smalltalk — это рекурсия понятия самого компьютера. Вместо разделения «компьютерной всячи50 Simondon, 51 Robson,... [стр. 16 ⇒]

Социокультурное значение ООП огромно. Часто говорят, что она стала началом индустриализации программной разработки и главным фактором в преодолении так называемого software crisis (длившегося примерно с конца 1960-х по середину 1980-х)53 . Подавляющее большинство создаваемых сегодня программ написаны на объектно-ориентированных языках. В нашем случае первостепенный интерес имеет следующее обстоятельство: среда разработки первого полностью объектно-ориентированного языка Smalltalk, созданная на базе уже упомянутого компьютера Xerox Alto, и была той программой, где был впервые реализован GUI (как мы его определили выше). В ходе её разработки оказалось, что элементы графического интерфейса — в частности, «окно» — наиболее органично описываются при помощи понятия объекта: «окно» имеет какие-то атрибуты (заголовок, размер, место на экране, статус: активно/не активно и пр.), т.е. структуры, и поведение (его можно свернуть, развернуть, переместить и пр.), т.е. операции. «Окно» — это часть пространства, визуально репрезентирующая объект. Если программа имеет многооконный интерфейс (multiple document interface) или многодокументный интерфейс с вкладками (tabbed document interface), то «окна» репрезентируют, кроме того, иерархические отношения между объектами. Изобретение GUI исторически неотделимо от изобретения понятия объекта (хотя последний возникает раньше). История коммерциализации и инкультурации GUI, начинавшегося как чисто экспериментальная разработка, неоднократно освещалась в литературе: в 1979 г. Стив Джобс посещает лабораторию Xerox PARC, где Алан Кэй и его коллеги демонстрируют ему среду языка Smalltalk, после чего Джобс заимствует идею GUI при разработке системы Mac OS. ООП широко распространяется вместе с GUI как наиболее естественный инструмент для его реализации. Сегодня GUI полностью интегрирован с ООП-технологией: за исключением каких-то экзотических случаев все элементы графического интерфейса, с которыми сталкиваются пользователи, представлены в коде как объекты (да и вся программа, как правило, представляет собой один сложно структурированный объект). Теперь мы наконец готовы уточнить генезис графического пользовательского интерфейса: (2) GUIIII = (клавиатура + дисплей + «мышь»)I + (ООП)II Однако и этого уточнения ещё недостаточно. За изобретением GUI стояла более конкретная абстракция объектно-ориентированной технологии, культурно-историческое значение которой пока что не оценено и не изучено54 . Для того, чтобы внести это последнее уточнение, проясним культурнофилософский смысл понятия объекта. 53 См.:... [стр. 18 ⇒]

Согласно наиболее распространённой в индустрии интерпретации ООПтехнологии60 , последняя покоится на трёх механизмах — инкапсуляции, полиморфизме и наследовании. Эти механизмы могут имплементироваться раздельно (скажем, модульное программирование также прибегает к инкапсуляции), поэтому важно их сочетание. Под инкапсуляцией понимается сокрытие и связывание структур и операций внутри объекта: это уменьшает количество сущностей, с которыми имеет дело программист. Полиморфизм означает, что одно и то же имя объекта используется для разных, но семантически схожих объектов (имя есть «двойственный символ»61 ) — тем самым достигается удобство в обращении с разными типами данных через единый интерфейс (например, оператор «+» может означать как арифметическое сложение, так и конкатенацию, т.е. склейку символов). Это помогает сосредотачиваться на семантике операций и абстрагироваться от их технической реализации. Наконец, наследование означает, что объекты наследуют или передают в наследство некоторые или все свои структуры и операции другим объектам, в результате чего выстраивается иерархия классов (класс есть абстрактное описание, или тип, объекта). Наследование позволяет прибегать к повторному использованию кода (code reuse), что экономит время разработки. Вернёмся к высказыванию Кэя. Его сравнение объекта с платоновской Идеей не единично. В работах по computer science сходство абстракций ООП с философемами античной классики — аристотелевских «вторичных субстанций» с классами, платоновской Идеи (Архетипа) с прототипом (первичный объект, служащий для генерации других объектов в так называемом прототипном стиле ООП), и пр., — является общим местом. Причём эта аналогия может быть прослежена вплоть до деталей: так, механизм полиморфизма повторяет проблематизацию «одноименности» и «соименности» (унивокации и эквивокации, говоря языком схоластики) у Аристотеля, а механизм наследования объектов (иерархия классов) порождает системы родовидовых классификаций, подобные аристотелевским62 . Более того: сам генезис платоновской Идеи подобен генезису объекта в информатике. Досократическая мысль была одержима вопросом о движении. Два крайних ответа на этот вопрос, как считается, были даны Гераклитом и Парменидом: первый утверждал, что бытие есть движение и изменение («всё течёт»), а второй — что бытие неизменяемо, поскольку движение логически невозможно (бытие подобно «глыбе прекруглого шара»). Изоб60 См.: Sebesta, Robert W. Concepts of Programming Languages. New Jersey: Pearson Education, 2006. 61 Определение, данное в оригинальной статье 1967 г.: Strachey, Christopher. Fundamental Concepts in Programming Languages // Higher-Order and Symbolic Computation, №13, 2000, p. 35. 62 См.: Hsu, Hansen. Connections between the Software Crisis and Object-Oriented Programming. URL: http://www.sigcis.org/files/Hsu – Software Crisis and OOP.pdf. Rayside, Derek; Campbell, Gerard T. Aristotle and Object-Oriented Programming: Why Modern Students Need Traditional Logic. URL: http://dis.eafit.edu.co/depto/documentos/p237rayside - Aristotle and Object-Oriented Programming. Why Modern Students Need Traditional Logic.pdf... [стр. 20 ⇒]

В дальнейшем Аристотель развил платоновскую идею Идеи, связав понятия изменяемости и неизменности с понятиями материи и формы. Идея как «вид» (idea этимологически связана с video) есть то, что возникает не в уме, а в умозрении (в отличие от натурфилософских первовеществ, данных только в уме, т.е. не обладающих формой, — таких как апейрон, огонь или число); так же и объект есть данная в уме абстракция, которая при этом первой из всех абстракций в истории информатики обрела зримость в качестве элементов GUI. Налицо, таким образом, не только сходство объекта с Идеей, но и сходство императивной и функциональной парадигм с мыслью Гераклита и Парменида соответственно: философемы этих досократиков подобны технологемам ИП и ФП, философемы Платона и Аристотеля — технологемам ООП. Отсюда можно сделать предварительный вывод, что эволюция абстракций в философии проходит те же этапы, что эволюция абстракций в информатике. Поскольку, как было сказано выше, античная метафизика зиждется на приоритете структуры (сама Идея как первое собственно философское изобретение утверждает приоритет структуры), а информатика — на приоритете операции, то их эволюции являются как бы инверсиями друг друга: там, где в метафизике структура, в информатике операция, и наоборот. Отличием информатики от метафизики является приоритет операции, а также более сжатый и краткий характер её эволюции. Может показаться странным, что те изобретения, которые делались, казалось бы, чисто случайно, на основе сугубо практических нужд (в стремлении убавить сложность репрезентации), выстраиваются в определённую эволюционную линию. Но помня о том, что операция имеет свой собственный схематизм, мы можем трактовать computer scientists не столько как инженеров (в индустриальном смысле), сколько как теоретиков практики. Теорию, согласно которой развитие операционной мысли в культуре следует за развитием структурной мысли и в сжатом кратком инверсированном виде повторяет его основные этапы, мы назовём гипотезой оператóрной рекапитуляции (другая формулировка гипотезы: эволюция computer science есть сжатый инверсированный эквивалент эволюции онто-теологии). Поскольку информатика есть двигатель постиндустриальной культуры, более «сильным», расширительным вариантом этой гипотезы был бы следующий: постиндустриальная, постсовременная культура — начавшаяся после «заката Европы», «конца истории» и «конца метафизики», — проходит те же этапы развития, что и западноевропейская культура в целом, начиная с Античности. Период 1900–1940-х гг. был периодом коллизии культурных «плит» и переходом к новому культурному циклу. Исчерпав свои внутренние потенции, западная культура как будто свернулась в одной-единственной вещи, дублирующей человеческие 21... [стр. 21 ⇒]

Ницше), что ни структура, ни операция не могут быть абсолютизированы: «эпистемологический монизм структуры и операции не остаётся верен сам себе и воссоздаёт в ходе своего развития тот термин, который он первоначально исключил»68 . Иначе говоря, если даже на каком-то этапе возникает синтез структуры и операции, в дальнейшем выясняется, что этот синтез был неуравновешен и клонился в сторону той или другой фазы, после чего синтетическое понятие дополняется противоположным ему. Таким образом, имеет место исследованный Гегелем диалектический процесс отрицания и отрицания отрицания (снятия): полагающая рефлексия структуры/операции («тезис») входит в противоречие с их внешней рефлексией («антитезис»), которая «снимается» определяющей рефлексией («синтез»), — система выходит на более высокий уровень абстракции, и диалектическое движение начинает повторяться. Так, уже в 1980-х гг. в программистской среде возникают сомнения в том, что понятие объекта пригодно для симуляции реального мира, который якобы состоит скорее из отношений, нежели из объектов. В итоге объект, первоначально будучи претензией на монизм, на синтез структуры и операции (т.е. сам будучи определяющей рефлексией структуры и операции), эволюционно занял место структуры, а комплементарная ей операция была воссоздана в виде понятия отношения (relation) между объектами. На этом новом этапе эволюции абстракций объект стал полагающей рефлексией, а понятие отношения — его внешней рефлексией. Программистский скепсис относительно объекта, возможно, был связан с искажением изначальных идей ООП в таких языках, как C++ или Java, где объекты интерпретируются скорее как некая расширенная структура данных и являются, по сути, просто прибавкой к императивной идеологии. В чисто объектно-ориентированном языке Smalltalk понятие объекта было сбалансировано понятием посылки сообщений (messaging), поэтому язык не нуждался в специальном, несинтаксическом выражении отношений. Для разъяснения сущности messaging Кэй обратился к одному из ключевых понятий дзен-буддизма, ma, — которое удивительным образом совпадает по смыслу с операцией: Мне жаль, что я когда-то ввел в употребление для этого предмета термин «объекты», потому что из-за него много людей сфокусировались на менее важной идее. Более важная идея — это «посылка сообщений»: это то, что является ядром Smalltalk/Squeak. . . У японцев есть словечко — ma — для обозначения «того, что между»... Ключ к созданию отличных и способных к росту систем — это в большей степени разработка того, как их модули коммуницируют друг с другом, чем того, какими должны быть их внутренние свойства и поведения. Подумайте об Интернете — чтобы жить, он (а) должен позволять существовать разным типам идей и реализаций, выходящим за пределами какого-либо единого стандарта, и (б) позволять существовать варьирующим68 Simondon,... [стр. 24 ⇒]

В начале 1990-х создаются специальные языки графического описания для формализации отношений посредством концептуальных схем (сonceptual schema), выражаемых с помощью диаграмм (диаграммы состояний, диаграммы взаимодействия и пр.); наиболее известный из них — UML (Unified Modeling Language)70 . Эти языки отношений прямо не предназначены для имплементации: уровень абстракции в них слишком высок для трансляции в эффективно работающий код (хотя такие трансляторы существуют); их цель — облегчить репрезентацию сложных программных комплексов. В результате противоречия между объектом и отношением в конце 1980х образуется их «синтез» в понятии шаблона проектирования (также: паттерн проектирования — software design pattern), заимствованном из теории архитектуры71 . Шаблон проектирования — это схема отношений между объектами, которая выступает общим, повторно используемым (reusable) решением какой-нибудь часто встречающейся в процессе разработки задачи (аналогом служат удачные, проверенные временем способы организации архитектурного пространства). Шаблон проектирования как новый этап эволюции абстракций есть определяющая рефлексия отношения объектов и их отношений. Шаблоны как общие решения существовали и ранее, но не были формализованы. В любом относительно крупном программном продукте, основанном на ООП, так или иначе используются какие-то шаблоны проектирования (даже если его создатели не подозревают о существовании этого понятия). Сегодня знание шаблонов (классическими считаются 23 типа, при этом изобретение новых типов не прекращается72 ) является стандартной компетенцией программиста-профессионала. С точки зрения нашей гипотезы, переход от объектов к шаблонам проектирования «одновременен» переходу к неоплатонизму, в рамках которого также подробно разрабатываются системы отношений между Идеями (в основном иерархические). На эту «одновременность», кроме того, указывает введение в таких языках, как Java, Objective-C, Smalltalk, Common Lisp и др., так называемого высшего типа (top type) — универсального класса, или объекта, содержащего в себе все возможные объекты в системе. Высший тип, очевидно, гомологичен Единому Плотина: все остальные объекты «эманируют» из него. Один из таких шаблонов проектирования (разработанный ещё до возникновения самого термина) был положен в основу архитектурного реше69 Kay, Alan. Prototypes vs classes was: Re: Sun’s HotSpot. URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html 70 См.: Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The Unified Software Development Process. Boston: Addison Wesley Longman, 1998. 71 Alexander, Christopher. A Pattern Language: Towns, Buildings, Construction. Oxford, New York: Oxford University Press, 1977. Об отношении между архитектурой и программированием см. текст К. Александера (1996): Gabriel, ibid., p. v-xi. 72 См.: Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John. Design Patterns: Elements of Reusable Object-Oriented Software. Boston: Addison-Wesley Professional, 1994. [стр. 25 ⇒]

Маклюэна на создание теории медиа 75 и дало право Р. Дебрэ говорить о медиологии как о «профанной христологии»76 . Это отступление в антропологию и философию религии должно подготовить нас к пониманию абстракций в коде, изобретённых на этапе тематизации объектов и отношений. Прежде всего нужно оговориться, что на этой стадии (конец 1980-х) мышление в computer science перестаёт быть в собственном смысле слова алгоритмическим и становится архитектурным. В развитых средствах ООП-разработки программа представлена не как растущий слоями кристалл (хотя на более низком уровне абстракции она продолжает оставаться текстом, прирастающим новыми строчками), а как векторная карта или план сооружения: таковы графические схемы отношений между объектами в визуальном языке UML. Соответственно, акцент в создании программ переносится с «кустарных» способов производства на систематизацию и организацию программистского труда, коммуникацию между разработчиками и т. д. — всё, что сегодня понимают под термином программная инженерия (software engineering). Одной из наиболее ранних и наиболее употребляемых в индустрии схем отношений между объектами является уже упомянутый паттерн проектирования (точнее, архитектурный паттерн — поскольку эта схема сама состоит из нескольких шаблонов) под названием Model–View–Controller (MVC). Паттерн был разработан сотрудником лаборатории Xerox PARC по имени Трюгве Реенскауг (Trygve Reenskaug) в 1979 г.77 Мотивом к созданию этой абстракции послужило стремление усовершенствовать устройство программ, использующих GUI. Идея Реенскауга сводилась к следующему: необходимо так распределить задачи между частями программы, чтобы можно было изменять любую из них, не затрагивая другие, но при этом чтобы эти части работали более слаженно. Согласно предложенной им схеме, в любой программе, использующей GUI, должны присутствовать 1) часть, отвечающая за знания (вычисление, хранение, трансляцию информации), — Модель (Model) («Это может быть один объект, что довольно неинтересно, или некая структура объектов»); 2) часть, отвечающая за «визуальную репрезентацию модели», — Представление, (View): «Представление привязано к своей модели (или части модели) и получает необходимые для презентации данные, задавая модели вопросы. Оно может также обновлять модель, посылая ей соответствующие сообщения»; 74 Валь,... [стр. 27 ⇒]

Лабораторная работа № 1 Тема. Простейшие классы и объекты Теоретическое введение. Классы представляют абстрактные типы данных с открытым интерфейсом и скрытой внутренней реализацией. В классах реализованы базовые принципы объектноориентированного программирования (ООП): 1) абстракция данных; 2) инкапсуляция – в классах объединяются данные и методы (функции) для работы с ними, так как лишь через методы возможен доступ к сокрытым данным класса; 3) наследование – в производных классах наследуются члены базового класса; 4) полиморфизм – возможность использования одних и тех же методов для работы с различными объектами базового и порожденных им классов. Определение простейшего класса без наследования имеет вид: class имя_класса { // по умолчанию раздел private – частные члены класса public: // открытые функции и переменные класса }; Имя класса является новым типом данных. Понятию переменной данного типа соответствует понятие объекта класса. Список членов класса включает описание данных и функций. Функции, описания которых находятся в определении класса, называются функциямичленами класса. Переменные и функции, объявленные в разделе класса по умолчанию или явно как private, имеют область видимости в пределах класса. Их можно сделать видимыми вне класса, если объявить в разделе public:. Обычно переменные объявляются в разделе private, а функции в разделе public. Классами в С++ являются также структуры (struct) и объединения (union). В отличие от класса члены структуры по умолчанию являются открытыми, а не закрытыми. Кроме того, объединения не могут наследоваться и наследовать. При реализации функциональной части класса могут быть использованы функции-члены класса, конструкторы, деструкторы, функции-операторы. Функции класса всегда объявляются внутри класса. Определение функции может находиться и внутри класса. Такие функции называются inline-функциями. Обычно определения 3... [стр. 3 ⇒]

Подпрограммы с локальными данными Рис. 1.6. Архитектура программы при ООП А б с т р а г и р о в а н и е - процесс вьщеления абстракций в предметной области задачи. Абстракция - совокупность существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют особенности данного объекта с точки зрения дальнейшего рассмотрения и анализа. В соответствии с определением применяемая абстракция реального предмета существенно зависит от решаемой задачи: в одном случае нас будет интересовать форма предмета, в другом вес, в третьем - материалы, из которых он сделан, в четвертом - закон движения предмета и т.д. Современный уровень абстракции предполагает объединение всех свойств абстракции (как касающихся состояния 19... [стр. 20 ⇒]

О г р а н и ч е н и е д о с т у п а - сокрытие отдельных элементов реализации абстракции, не затрагивающих существенных характеристик ее как целого. Необходимость ограничения доступа предполагает разграничение двух частей в описании абстракции: интерфейс - совокупность доступных извне элементов реализации абстракции (основные характеристики состояния и поведения); реализация - совокупность недоступных извне элементов реализации абстракции (внутренняя организация абстракции и механизмы реализации ее поведения). Ограничение доступа в ООП позволяет разработчику: выполнять конструирование системы поэтапно, не отвлекаясь на особенности реализации используемых абстракций; легко модифицировать реализацию отдельных объектов, что в правильно организованной системе не потребует изменения других объектов. Сочетание объединения всех свойств предмета (составляющих его состояния и поведения) в единую абстракцию и ограничения доступа к реализации этих свойств получило название инкапсуляции. М о д у л ь н о с т ь - принцип разработки программной системы, предполагающий реализацию ее в виде отдельных частей (модулей). При выполнении декомпозиции системы на модули желательно объединять логически связанные части, по возможности обеспечивая сокращение количества внешних связей между модулями. Принцип унаследован от модульного программирования, следование ему упрощает проектирование и отладку программы. И е р а р х и я - ранжированная или упорядоченная система абстракций. Принцип иерархичности предполагает использование иерархий при разработке программных систем. В ООП используются два вида иерархии. Иерархия «целое/часть» - показывает, что некоторые абстракции включены в рассматриваемую абстракцию как ее части, например, лампа состоит из цоколя, нити накаливания и колбы. Этот вариант иерархии используется в процессе разбиения системы на разных этапах проектирования (на логическом уровне - при декомпозиции предметной области на объекты, на физическом уровне - при декомпозиции системы на модули и при вьщелении отдельных процессов в мультипроцессной системе). Иерархия «общее/частное» - показывает, что некоторая абстракция является частным случаем другой абстракции, например, «обеденный стол конкретный вид стола», а «столы - конкретный вид мебели». Используется при разработке структуры классов, когда сложные классы строятся на базе более простых путем добавлеьшя к ним новых характеристик и, возможно, уточнения имеющихся. 20... [стр. 21 ⇒]

Один из важнейших механизмов ООП - наследование свойств в иерархии общее/частное. Наследование - такое соотношение между абстракциями, когда одна из них использует структурную или функциональную часть другой или нескольких других абстракций (соответственно простое и множественное наследование). Т и п и з а ц и я - ограничение, накладываемое на свойства объектов и препятствующее взаимозаменяемости абстракций различных типов (или сильно сужающее возможность такой замены). В языках с жесткой типизацией для каждого программного объекта (переменной, подпрограммы, параметра и т. д.) объявляется тип, который определяет множество операций над соответствующим программным объектом. Рассматриваемые далее языки программирования на основе Паскаля используют строгую, а на основе С среднюю степень типизации. Пр имечание. Интересно, что в C++ строгость типизация возрастает по сравнению с С, хотя ограничения типизации в этом языке можно почти полностью подавить. [стр. 22 ⇒]

Несмотря на то, что принципиально ООП возможно на многих языках программирования, желательно для создания объектно-ориентированных программ использовать объектно-ориентированные языки, включающие специальные средства, например, Borland Pascal (начиная с версии 5.5), C++, Delphi и т.д. В табл. 1.1 представлены сравнительные характеристики рассматриваемых в следующих главах языковых средств. Самая простая объектная модель использована при разработке Borland Pascal 7.0. Она специально создавалась для облегчения перехода программистов на использование технологии ООП и не поддерживает абстракции метаклассов, почти не содержит специальных средств сокрыгия реализации объектов. Но даже в таком варианте она позволяет создавать достаточно сложные системы. Объектные модели остальньпс языков являются практически полными. Особое место занимают объектные модели Delphi и C++Builder. Эти модели обобщают опыт ООП для MS DOS и включают некоторые новые средства, обеспечивающие эффективное создание более сложных систем. На базе этих моделей созданы визуальные среды для разработки приложений Windows. Сложность программирования под e n d o w s удалось существенно 22... [стр. 23 ⇒]

Этапы разработки программных систем с использованием ООП. Процесс разработки программного обеспечения с использованием ООП включает четыре этапа: анализ, проектирование, эволюция, модификация. Рассмотрим эти этапы. А н а л и з . Цель анализа - максимально полное описание задачи. На этом этапе выполняется анализ предметной области задачи, объектная декомпозиция разрабатываемой системы и определяются важнейшие особенности поведения объектов (описание абстракций). По результатам анализа разрабатывается структурная схема программного продукта, на которой показываются основные объекты и сообщения, передаваемые между ними, а также вьшолняется описание абстракций. П р о е к т и р о в а н и е . Различают: логическое проектирование, при котором принимаемые решения практически не зависят от условий эксплуатации (операционной системы и используемого оборудования); физическое проектирование, при котором приходится принимать во внимание указанные факторы. Логическое проектирование заключается в разработке структуры классов: определяются поля для хранения составляющих состояния объектов и алгоритмы методов, реализующих аспекты поведения объектов. При этом используются рассмотренные вьппе приемы разработки классов (наследование, композиция, наполнение, полиморфизм и т.д.). Результатом является иерархия или диаграмма классов, отражающие взаимосвязь классов, и описание классов. Физическое проектирование включает объединение описаний классов в модули, выбор схемы их подключения (статическая или динамическая компоновка), определение способов взаимодействия с оборудованием, с операционной системой и/или другим программным обеспечением (например, базами данных, сетевыми программами), обеспечение синхронизации процессов для систем параллельной обработки и т.д. Э в о л ю ц и я с и с т е м ы . Это процесс поэтапной реализации и подключения классов к проекту. Процесс начинается с создания основной программы или проекта будущего программного продукта. Затем реализуются и подключаются классы, так чтобы создать грубый, но, по возможности, работающий прототип будущей системы. Он тестируется и отлаживается. Например, таким прототипом может служить система, включающая реализацию основного интерфейса программного продукта (передача сообщевий в отсутствующую пока часть системы не вьшолняется). В результате мы получаем работоспособный прототип продукта, который может быть, например, показан заказчику для уточнения требований. Затем к системе подключается следующая группа классов, например, связанная с реализацией некоторого пункта меню. Полученный вариант также тестируется и отлаживается, и так далее, до реализации всех возможностей системы. 24... [стр. 25 ⇒]

Таким образом, в иерархическом дереве классов по мере удаления от корня мы встречает все более слоэюные классы, экземплярами которых будут объекты с более слоэюной структурой и поведением. Наследование свойств в иерархии существенно упрощает работу программиста. В настоящее время созданы библиотеки наиболее часто встречающихся классов, которые можно использовать вновь и вновь, строя на их основе классы для решения различных задач. Простой полиморфизм. При создании иерархии классов может обнаружиться, что некоторые свойства объектов, с о х р а н я я н а з в а н и е , и з м е н я ю т с я по сути. Для реализации таких иерархий в языке программирования должен быть предусмотрен полиморфизм, обеспечивающий возможность задания различных реализаций некоторого единого по названию метода для классов различных уровней иерархии. В ООП такой полиморфизм называется простым, а методы, имеющие одинаковое название - статическими полиморфными. Совокупность полиморфных методов с одним именем для иерархии классов образует единый полиморфный метод иерархии, в котором реализация полиморфного метода для конкретного класса представляет отдельный аспект. Пр имечание. Термин «полиморфизм» в программировании, в соответствии со своим изначальным смыслом («многообразие»), используется для обозначения встроенного механизма определения соответствия кода функции типу параметров. Такой механизм реализуется не только в средствах ООП. Различают несколько терминов, связанных с конкретными механизмами реализации полиморфизма для различных случаев: чистый полиморфизм - используется для обозначения того, что один код функции может по-разному и н т е р п р е т и р о в а т ь с я в зависимости от типа аргументов; используется в языках высокого уровня абстракции, например, в язьже LISP или SMALLTALK; перегрузка {полиморфные имена функций) - используется, когда определяется несколько функций с одним именем - одно и то же имя функции может многократно использоваться в разных местах программы; выбор нужной функции может определять типами аргументов, областью видимости (внутри модуля, файла, класса и т.д.); если выбор определяется типом... [стр. 42 ⇒]

Механизм наполнения в основном используется для подключения объекта или структуры объектов к некоторому классу, реализующему управление сразу всей структурой. 1.7. Дополнительные средства и приемы разработки классов Рассмотренные в предыдущем разделе средства разработки классов являются основными. Они предусматриваются принципами ООП. Однако к настоящему моменту постепенно складывается более сложная модель ООП, включающая такие понятия, как метаклассы, контейнерные классы, делегирование методов, параметризованные классы. Появление в языках программирования соответствующих средств позволяет создавать более эффективные программы. Метаклассы. Дальнейшее развитие идеи реализации полиморфных объектов привело к появлению более высокого уровня абстракции метаклассов. Метакласс - тип, значеьшями которого являются классы, как ссылки на типы. Переменные типа метакласса можно использовать вместо явного указания класса в соответствии с традиционными правилами косвенного доступа (рис. 1.29). Реализация метаклассов базируется на использовании специальных таблиц, в которых хранится информация о классе: имя класса, имя классародителя, адреса методов и т.д. Поскольку эти таблицы используются во время выполнения программы, то они получили название RTTI (Run Time Type Information - «информация о типе времени вьшолнения»). Эти же таблицы используются для реализации следующих операций: операция проверки принадлежности объекта заданному классу или его потомкам; операция уточнения класса объекта - отличается от операции явного переопределения типа тем, что перед переопределением проверяется, принадлежит ли объект данному классу или его потомкам; специальные операции определения, модификации или проверки свойств класса (как типа) - для реализации этих операций язык программирования Прямое обращение Косвенное обращение к классу к классу Переменная метакласса Класс Класс Рис. 1.29. Организация прямого и косвенного доступа к классу 48... [стр. 49 ⇒]

СРЕДСТВА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ В BORLAND PASCAL 7.0 При разработке языка Borland Pascal 7.0 использована логически завершенная, но самая простая объектная модель. В этой модели отсутствуют специальные средства сокрытия реализации классов и noddepjtcKu дополнительных средств и приемов разработки классов (абстракций метаклассов, делегирования и т. д.). Задача данной главы показать преимущества далее такой упрощенной модели ООП по сравнению с ранее известными подходами в программировании. [стр. 60 ⇒]

Основная концепция (2) Абстракция - Центральный элемент ООП. Данные с помощью абстракции преобразуются в объекты, а последовательность обработки этих данных превращается в набор сообщений, передаваемых между этими объектами. Каждый из объектов имеет свое собственное уникальное поведение. С объектами можно обращаться как с конкретными сущностями, которые реагируют на сообщения, приказывающие им выполнить какие-то действия. [стр. 4 ⇒]

Словарь ООП (1) Абстрагирование (abstraction) -- метод решения задачи, при котором объекты разного рода объединяются общим понятием (концепцией), а затем сгруппированные сущности рассматриваются как элементы единой категории. Абстракция (abstarction) -- существенные характеристики объекта, которые отличают его от всех других видов объектов и четко определяют особенности данного объекта с точки зрения дальнейшего рассмотрения и анализа. Абстрактный класс (abstract class) -- класс, который не может быть использован для создания экземпляров, а служит исключительно для порождения других классов. Абстрактный метод (abstract method) -- метод, который не может быть вызван без предварительного доопределения. Автоматическая переменная (automatic variable) -- переменная, для которой память выделяется автоматически при входе в процедуру (функцию, метод или блок); противопоставляется динамической переменной, память для которой отводится явной командой пользователя. [стр. 16 ⇒]

Например: манипулирование объектом “текстовое поле” – это ввод в него данных, изменение цветового оформления, установка шрифтов и их размеров и т.д. Программно каждый объект определяется как класс. Создаваемые объекты в VB могут управляться только изменением свойств и вызовом методов. В программной реализации внутри создаваемых объектов-элементов управления не должно быть никаких переменных public. Для упрощения процедур разработки и отладки программ рекомендуется создавать небольшие объекты, которые выполняют несколько задач вместо чрезмерно сложных объектов с большим количеством внутренних данных и связей, требующихся для управления, или сотен свойств и методов. События, методы и свойства. В Visual Basic манипулировать объектами можно двумя способами: • изменяя свойства объекта; • заставляя объект выполнять специфические задания путем активизации метода (методов), ассоциированных с этим объектом. Оба эти способа ассоциируются с наступлением некоторого пользовательского или системного события. Событие – это действие или ситуация, связанная с объектом (щелчок кнопки мыши или нажатие клавиши). События также могут инициироваться в программном коде приложения (загрузка формы в память) или непосредственно в системной среде. Для обработки события можно создать свой программный код в процедурах обработки событий, которые вызываются автоматически. Свойства определяют представление, поведение и другие черты объекта. Цвет фона и заголовок формы, таблица БД (источник записей для формы) являются свойствами тех или иных объектов. Методы – это программные процедуры, которые выполняют некоторую обработку, связанную с объектом. Например, если щелчком на программной кнопке требуется открыть форму, необходимо соответствующий программный код добавить к телу процедуры Click () командной кнопки. Свойства и методы называются также интерфейсом объекта. Стандартные методы VB подразделяются на две категории: 1. Процедуры, реагирующие на стандартные события – это набор событий, автоматически обрабатываемых для каждого объекта. Например, загрузка формы и вывод ее на экран. 2. Стандартные методы, вызываемые явно в программном коде разработчика. Классы. Важнейшее понятие ООП – класс. Класс обычно описывается как шаблон, проект, из которого впоследствии будет создан объект. Каждый объект в этом случае является экземпляром класса. Если объекты существуют в приложениях, то класс это абстракция, объединяющая объекты в одну группу согласно их свойствам и поведению в среде окруже... [стр. 5 ⇒]

Код, в котором применяется принцип полиморфизма или реализован интерфейс, намного легче сопровождать и расширять, чем код, изобилующий проверками типов. 7. Не злоупотребляйте механизмом рефлексии. Механизм рефлексии позволяет создавать программы с высоким уровнем абстракции, где поля и методы определяются во время выполнения. Такая возможность чрезвычайно полезна для системного программирования, но для прикладного — практически не нужна. Рефлексия — очень хрупкий механизм, поскольку компилятор не может помочь в обнаружении ошибок. Все ошибки проявляются во время выполнения программы и приводят к возникновению исключений. В этой главе было показано, каким образом в Java поддерживаются основные понятия и принципы ООП: классы, наследование и полиморфизм. А в следующей главе мы затронем две более сложные темы, которые очень важны для эффективного программирования на Java: интерфейсы и лямбда-выражения. [стр. 265 ⇒]

Итак, основой объектно-ориентированной технологии является так называемая объектная модель, которая возникает как результат объектно-ориентированной декомпозиции. Она выделяет основные абстракции предметной области, определяет классы абстракций и выясняет, какими данными (атрибутами) описывается каждая абстракция, какую функциональность эти абстракции должны обеспечивать. В отличие от традиционных технологий программирования, объектно-ориентированная технология представляет программу как совокупность классов и объектов, взаимодействующих друг с другом. Объект – конкретная материализация абстракции; сущность с хорошо определенными границами, в которой инкапсулированы состояние и поведение. Объект ООП – инкапсулированная структура, имеющая атрибуты и методы. Термин инкапсулированная структура означает, что объект является самодостаточным, программы, внешние по отношению к объекту, ничего не знают о его структуре и такое знание им не требуется. «Внешний» вид объекта называется его интерфейсом. В таком понимании объект – это черный ящик, нам неизвестно что у него внутри, мы лишь можем вызвать его методы и только через них взаимодействовать с ним. Кроме этого объекты могут принадлежать иерархии «от общего к частному», которая реализуется путем наследования. Инкапсулированные состояния объекта могут быть как простыми типами данных, так и другими объектами, или даже массивами объектов. Каждый объект содержит определенную совокупность методов, классы взаимодействуют друг с другом посредством механизма сообщений. Объекты идентифицируются с помощью специальных указателей дескрипторов. Методы объектов ООП представляют собой последовательности инструкций, выполняемых объектом. Например, у объекта может быть метод, отображающий данный объект, создающий данный объект и изменяющий данный объект. Предметная область моделируется как множество классов взаимодействующих объектов. Объект характеризуется набором свойств, которые являются как бы его пассивными характеристиками, и набором методов работы с этим объектом. Работать с объектом можно только с использованием его методов. Атрибуты объекта могут принимать множество допустимых значений, набор конкретных 203... [стр. 203 ⇒]

Однако иногда неправильное использование потенциала абстракции ООП может серьезно осложнить понимание программного кода. Если классы наслоены друг на друга слишком глубоко, программный код становится малопонятным  – возможно, вам придется изучить множество классов, чтобы выяснить, что делает единственная операция. Например, однажды мне пришлось работать с  библиотекой, написанной на языке C++, содержащей тысячи классов (часть которых была сгенерирована машиной) и до 15 уровней наследования. Расшифровка вызовов методов в такой сложной системе классов часто оказывалась неподъемной задачей: даже в простейшую операцию оказывались вовлеченными сразу несколько классов. Логика системы оказалась такой многослойной, что в некоторых случаях, чтобы понять принцип действия какого-либо участка программного кода, требовалось несколько дней копаться в нескольких файлах. Здесь также вполне применимо одно из самых универсальных правил языка Python: не усложняйте решение задачи, если оно не является таковым. Обертывание программного кода несколькими слоями классов на грани непостижимости – всегда плохая идея. Абстракция – это основа полиморфизма и инкапсуляции, и  при грамотном использовании она может быть весьма эффективным инструментом. Однако вы упростите отладку и  сопровождение, если сделаете интерфейсы своих классов интуитивно понятными. Избегайте чрезмерной абстракции и сохраняйте иерархии своих классов короткими и плоскими, если не существует веских причин сделать иначе. [стр. 907 ⇒]

Например, вряд ли стоит доказывать необходимость обеспечения свойства сохраняемости для классов объектов систем объектно-ориентированных баз данных. Абстрагирование реализует свойство концентрации внимания на внешних особенностях объектов и позволяет отделить самые существенные особенности поведения от несущественных. Минимизацию связей, когда интерфейс объектов содержит только существенные аспекты поведения, реализует принцип барьера абстракции. Таким образом, абстракция выражается через свойства, присущие всем объектам заданного абстракцией класса и, в тоже время, отличающие объекты заданного ей класса от объектов других классов. Определение понятия абстракция, таким образом, содержит конфликтное условие, которое порождает многие классификационные проблемы. Суть такого конфликта заключается в необходимости совмещения в абстракции элементов общности и исключительности существенных свойств. Очевидно, что естественная природа выделения классов объектов предметной области обостряет указанный конфликт, доводя его до состояния неразрешимых противоречий. Именно с этим аспектом связаны главные трудности построения систем объектно-ориентированных баз данных. Применение механизмов абстрагирования в рамках объектноориентированного подхода формулирует главное правило — представление предметной области в объектной модели. Классификационная схема, основанная на той или иной системе знаний о предметной области и классификационной методологии, обеспечивает выделение классов объектов. Заголовочное определение классов, описывается в виде абстракций, интерфейсные свойства которых обладают качествами существенности, общности для данного класса и различимости для отделения объектов других классов. Отметим, что совокупность классифицированных абстракций предметной области «моделирование систем S» в общем случае состоит из абстракций двух типов: — абстракции определения объектов данных предметной области, которые называются абстракциями данных; — абстракции определения модельных элементов представления данных, которые называются абстракциями моделей или модельными абстракциями. Для систем объектно-ориентированного программирования абстракции данных определяют классы объектов программирования оконного интерфейса, работы с Internet, доступа в БД, связывания и внедрения объектов ActiveX и т. д. Абстракции моделей для систем ООП соответствуют структурным абстракциям. Для обоих типов абстракций систем ООП характерным является то, что определяемые абстракциями объекты выступают одновременно и в роли данных, и в роли инструментов управления такими данными. На188... [стр. 188 ⇒]

...п.). И н к а п с у л я ц и я реализует свойство объектной модели, связанное с абстрагированием и обеспечивающее разделение описания класса на интерфейс и реализацию. В интерфейсной части описания класса содержится суть определения классифицированной абстракции, т. е. то, что присуще всем объектам задаваемого абстракцией класса. Через интерфейс объекты взаимодействуют, и именно интерфейс является предметом интеграционной отладки при разработке проектируемой системы. Таким образом, интерфейс представляет собой формальное описание абстракции средствами реализации проектируемой системы. Реализация класса точно соответствует названию, и содержит детали реализации интерфейса (т. е. абстракции) при построении объектов данного класса. Разделение на интерфейс и реализацию соответствует определению внешнего (логического) и внутреннего (физического) устройства объектов. Принцип инкапсуляции соответствует сути вещей, интерфейс при этом играет роль определения степени интереса и полезности знания такой сути. Объединение инкапсуляции с абстрагированием обеспечивает формирование видимости единой сущности множества физически различных объектов. Так, в технологии БД, табличная форма представления данных является интерфейсом, в то время как реализация таблиц в разных СУБД физически различна (начиная с различий форматов файлов — db, dbf и др.). Интерфейс и реализация исполняются в среде разработки проектируемой системы, поэтому можно построить следующую логическую цепочку взаимосвязи понятий: интерфейс есть исполнение абстракции, а реализация есть исполнение интерфейса. Например, в системах ООП интерфейс и реализация исполняются на языках C++, Object Pascal и др. Для систем объектно-ориентированных БД смысл инкапсуляции, в первую очередь, связан с разделением модельных представлений абстракций данных и реализации объектов данных одного классификационного раздела в различном схемном исполнении. Логическая последовательность взаимосвязи понятий в этом случае следующая. Модельные абстрагирование и инкапсуляция исполняют концептуальные, фундаментальные, инфологические и даталогические представления БД в реляционной модели, а абстрагирование и инкапсуляция данных предметной области исполняют собственно реализацию объектно-ориентированной базы данных с применением расширенного реляционного подхода. Таким образом, объектная модель ООБД многослойна и включает ирархию объектных представлений моделей и данных с реализацией всех уровней объектной модели БД в реляционной модели данных 189... [стр. 189 ⇒]

Разработчик: Хм, но разве дело не сводится к ОО-проектированию? Если я следую принципам инкапсуляции, знаю об абстракции, наследовании и полиморфизме, то зачем мне думать о паттернах проектирования? Для чего тогда были нужны те курсы ОО-проектирования? Я думаю, паттерны проектирования полезны только тем, кто не разбирается в ОО-проектировании. Гуру: О, это одно из известных заблуждений объектно-ориентированной разработки: будто знание основ ООП автоматически позволит вам строить гибкие, удобные в сопровождении и пригодные к повторному использованию системы. Разработчик: Нет? Гуру: Hет. Более того, принципы построения ОО-систем, обладающих такими свойствами, далеко не всегда очевидны. Разработчик: Кажется, я начинаю понимать. И на основе этих неочевидных принципов построения объектно-ориентированных систем были сформулированы... Гуру: ...да, были сформулированы паттерны проектирования. [стр. 67 ⇒]

Граф наследования класса OpenFileDialog устроен так: sealed class OpenFileDialog : FileDialog {…} в свою очередь: abstract class FileDialog : CommonDialog {…} в свою очередь: abstract class CommonDialog : Component {…} в свою очередь: class Component : MarshalByRefObject, IComponent, IDisposable {…} Формирование как конкретных понятий, так и абстрактных понятий, возможно производить двумя способами, через наследование классов и/или через композицию объектов. Если некоторая абстракция подразумевает несколько реализаций (конкретик), то обычно применяют наследование. Например, абстракция FileDialog имеет две конкретные реализации, это классы OpenFileDialog и SaveFileDialog. Абстракция задает общий интерфейс взаимодействия с конкретными реализациями, тем самым формируя понятие общего типа. Конкретные классы могут поразному реализовать абстрактный интерфейс, главное, чтобы имена методов, составляющих общий интерфейс взаимодействия, соответствовали роду выполняемой ими деятельности. Но, подход с наследованием разрушает гибкость и формирует хрупкость. Хрупкость базового класса – фундаментальная проблема в ООП. Проблема хрупкого базового класса заключается в том, что изменения, внесенные в реализацию базового класса, могут негативно сказаться на работе производных классов. Наследование формирует сильнейшую форму связанности (coupling - мера зависимости) из всех возможных и разорвать эту связанность невозможно. Соответственно потеря гибкости означает – затруднение модификации, расширения и повторного использования как абстракции, так и реализации (конкретики). Использование паттерна Bridge позволяет решить описанные выше проблемы. Предлагается воспользоваться паттерном Bridge для построения простейшей программы, которая рисует заданные геометрические фигуры линиями определенного стиля. В качестве примера рассмотрим треугольник. Треугольник — это абстракция. Треугольник (в евклидовом пространстве) — это геометрическая фигура, образованная тремя отрезками, которые соединяют три не лежащие на одной прямой точки. Предлагается рассмотреть треугольники не в смысле геометрических типов (прямоугольные, равнобедренные и др.) а как выражения треугольных форм предметов из объективной реальности. Например, школьный треугольник, треугольник для бильярда и музыкальный треугольник. [стр. 106 ⇒]

4. Ларман К. Применение UML 2.0 и шаблонов проектирования. 3-е изд. — М.: Вильямс, 2004. Еще один учебник по разработке ПО с уклоном в объектно-ориентированные методы: анализ и проектирование. 5. Буч Г. Объектно-ориентированный анализ и проектирование. — М.: Вильямс, 2003. Еще одна классическая книга по объектно-ориентированному программированию, но, в отличие от книги Бертрана Мейера, имеет менее формальный и более описательный характер. В книге потрясающе описаны проблема сложности ПО, роли абстракции и иерархии, наиболее популярные на сегодняшний день методологии разработки и многое другое. 6. Эванс Э. Предметно-ориентированное проектирование. — М.: Вильямс, 2003. Многие ассоциируют DDD (Domain-Driven Design) со всякими новомодными штучками наподобие Event Sourcing, CQRS или на худой конец с рядом enterprise-паттернов и обязательным выделением сборок Domain и DataAccess. На самом деле основная цель любого вида проектирования заключается в моделировании предметной области, и любая книга по ООП или ФП говорит о том, как создавать модели, наиболее близкие к реальному миру. Классическая книга Эрика Эванса дала толчок развитию этой новой области проектирования. Прочесть ее обязательно. 7. Мартин Р. Принципы, паттерны и методики гибкой разработки на язы­ке C#. — СПб.: Символ-Плюс, 2011. Многие разработчики считают книгу Роберта Мартина чуть ли не библией разработки, но я с этим категорически не согласен. В отличие от других книг из этого списка, книга Роберта довольно поверхностна, эмоциональна и содержит большое количество спорных моментов. Я не советовал бы читать эту книгу неопытным разработчикам, поскольку она может существенно исказить понимание вопросов проектирования. Более подробный критический анализ книги Мартина можно найти в моей статье «Критика книги Боба Мартина “Принципы, паттерны и методики гибкой разработки на языке C#”» в блоге по адресу http://sergeyteplyakov.blogspot.ru/2013/12/aboutagile-principles-patterns-and.html. 8. Beck K. Test-Driven Development: By Example. — 2002. Возрастная книга, но если вы хотите понять, что же такое TDD с точки зрения его автора, то лучшего источника не найти. Книга легко читается, в ней довольно много практических примеров, и она не слишком устарела, несмотря на свой возраст. 9. Freeman S., Pryce N. Growing Object-Oriented Software Guided by Tests. — 2009. Одна из лучших книг для изучения TDD вообще и тестирования в частности. [стр. 314 ⇒]

Задачі простору проблем предметної області або окремих членів сімейства, як правило, визначаються різними предметно-орієнтованими мовами. В даному випадку термін «мова» використовується в загальному розумінні. Тобто така мова може бути подана як засіб опису специфічних понять ПрО, різних аспектів функціонування задач за допомогою операції взаємодії членів сімейств або їх складових і т.п. Поняття ПрО можуть бути поданні також процедурами, функціями, методами, як в ООП. Вони, як відомо, зберігаються в бібліотеках або вбудовуються в універсальну мову програмування (наприклад у С++, С# тощо). Коли в таку мову додаються різного типу абстракції опису різних задач ПрО, її називають модульною предметно-орієнтованою мовою. Задачі можуть бути функціонального (наприклад, бухгалтерські, кадрові тощо) та системного (наприклад, захист даних, безпека, взаємодія тощо) типів. Специфікація задач домену може виконуватися декількома предметно– орієнтованими мовами, кожній з них притаманна своя специфічна мова. До предметно-орієнтованих мов відносять такі: – мова опису специфіки домену; – мова опису функціональних задач домену; – мова опису аспектів взаємодії, синхронізації компонентів у середовищі; – мова опису захисту даних та безпеки виконання сімейства систем; – мова опису інтерфейсів (PDL, IDL тощо). Предметно-орієнтована мова – DSL. Вона вналежить до класу мов опису специфіки ПрО або домену, властивої саме цьому домену. Опис кожного члена сімейства може містить мову опису специфіки задач домену і генеруючої моделі домену GDM (Generative Domain Model), яка відображає склад домену із членів сімейства, специфікованих також у предметно-орієнтованих мовах. Мова DSL не є новим винаходом, оскільки загальні абстракції програмування були визначені й вбудовані в мови загального призначення. І хоча мова DSL створюється багато років і для кожної ПрО є свій варіант мови, її застосування для специфікації особливостей ПрО не забезпечує формування повного уявлення про предметну область, оскільки вона дає лише засоби визначення загальних рис ПрО. Відомо, що будь-яка мова має визначену область застосування, проте мова DSL є більш спеціалізованою, ніж інші мови програмування (Паскаль, Кобол), що створювалися для розв’язання конкретних типів задач (обчислювальних, економічних). Порівняно з ними, DSL близька до описових мов, таких, як HTML, XML. Вона має специфічні особливості порівняно з мовами загального призначення, а саме: – абстракції DSL забезпечують визначення концепцій і абстрактних понять у предметній області; – синтаксис мови DSL може надавати засоби природного опису понять домену і запобігати синтаксичній неузгодженості, що буває при використанні мови загального призначення; – перевірка опису в DSL вимагає статичних аналізаторів, що можуть знайти більше помилок, ніж аналізатори загального призначення, і дати повідомлення про них цією ж мовою, що є більш зрозумілим для фахівців у предметній області;... [стр. 122 ⇒]

Delphi. Готовые алгоритмы ООП 346 абстракция данных 346 инкапсуляция 346 многократное использование 349 наследование 350 парадигмы 351 агрегат 353 дружественный класс 356 единственный объект 359 интерфейс 356 итератор 354 контролирующий объект 353 Модель/Вид/Контроллер 364 сериализация 361 составной объект 353 управляющий объект 351 фабрика 357 фасад 357 полиморфизм 349 Очередь 65 FIFO 65 многопоточная 73 на основе связанного списка 70 с приоритетом 71 циклическая 67... [стр. 374 ⇒]

Класс - это абстрактное понятие, сравнимое с понятием категория в его обычном смысле. Класс в объектно-ориентированном программировании - это абстрактный тип данных, который включает в себя не только данные, но и функции и процедуры. Функции и процедуры класса называются методами и содержат исходный код, предназначенный для обработки внутренних данных объекта данного класса. Класс можно также охарактеризовать так: Класс - описание множества объектов и выполняемых над ними действий. Секция методов. Первыми формами модульности, появившимися в языках программирования, были процедуры и функции. Они позволяли задавать определенную функциональность и многократно выполнять один и тот же параметризованный программный код при различных значениях параметров. Поскольку функции в математике использовались издавна, то появление их в языках программирования было совершенно естественным. Уже с первых шагов процедуры и функции позволяли решать одну из важнейших задач, стоящих перед программистами, - задачу повторного использования программного кода. Встроенные в язык функции давали возможность существенно расширить возможности языка программирования 4.2 Процедуры и функции - методы класса Долгое время процедуры и функции играли не только функциональную, но и архитектурную роль. Весьма популярным при построении программных систем был метод функциональной декомпозиции "сверху вниз", и сегодня еще играющий важную роль. Но с появлением ООП архитектурная роль функциональных модулей отошла на второй план. Для объектно-ориентированных языков, к которым относится и язык C#, в роли архитектурного модуля выступает класс. Программная система строится из модулей, роль которых играют классы, но каждый из этих модулей имеют содержательную начинку, задавая некоторую абстракцию данных. Процедуры и функции связываются теперь с классом, они обеспечивают функциональность данных класса и называются методами класса. Главную роль в программной системе играют данные, а функции лишь служат данным. В C# процедуры и функции существуют только как методы некоторого класса, они не существуют вне класса. [стр. 7 ⇒]

Получается, что для описания знаний о реальном мире число видов элементов семантической сети стремится к бесконечности. Внешне OWL напоминает многие существующие технологии, что не удивительно в связи с преобладанием XML-синтаксиса и декларированным использованием объектноклассовой парадигмы. Но OWL – пытается претендовать на логический язык, где каждая конструкция имеет строго определенный смысл. Объектно-ориентированный подход (ООП) в OWL характеризуется реализацией неких подходов моделирования относительно конкретного объекта, и поэтому имеет мало общего с реальным ООП, используемым в программировании. Более того, так как язык Web-онтологий является строго декларативным и логическим, то, следовательно, OWL не присущи компоненты ООП, такие как, например, методы. Рассуждения в OWL основаны на четкой логике, где нет ничего похожего на наследование, а уж тем более на наследование с исключениями или с переопределением. Важное различие между базами данных и OWL заключается в том, что информация, хранимая в базе, определяется посредством схемы базы данных и ограничений целостности. Если схема не поддерживает хранение определенных типов данных или данные нарушают принятые ограничения целостности, тогда эта информация не может быть сохранена в базе данных. OWL же позволяет связать информацию произвольного типа практически с любым объектом, если в онтологии ничего не противоречит этой связи (так как новая информация онтологий не может опровергать предыдущую информацию). При этом возможность таких противоречий разработчик онтологии должен каким-то фантастическим образом учитывать самостоятельно. Сделаем неутешительные выводы из изложенного и опыта многочисленных применений: описывая идентичные знания об одной и той же предметной области с использованием OWL, множество разработчиков получают разные семантически не сопоставимые, не совместимые, противоречивые, субъективные графы. То есть каждый автор претендует на свою отдельную версию фрагмента "модели знаний". Для нас же вся эта совокупность противоречивых несопоставимых авторских графов выглядит скорей НЕ ЗНАНИЕМ. Как в этом разноголосом информационном шуме ориентироваться? Кроме того, разработчики OWL считают, что основное преимущество OWL состоит в поддержке концептуального моделирования предметной области, правда предупреждают, что в ходе изучения процессов на концептуальном уровне "не стоит удивляться иррелевантному низкому уровню деталей реализации". С помощью OWL, якобы можно описать часть схем сущность-связь и UML-диаграмм на уровне неких абстракций, но опять-таки обещания призрачны и не конкретны. Декларируется, что концептуальные модели на базе OWL могут использоваться для «объединения несовместимых информационных систем и информации двух приложений баз данных с совершенно разными схемами данных, однако сходными (во всяком случае, на первый взгляд)». А что делать с тремя, десятью, миллионами программных приложений с не совсем похожими «на первый взгляд» схемами данных? Опять нам предлагается некий умозрительный многоэтапный подход к описанию реальной предметной области без проверки на адекватность реальной жизни. Может хватит производить бесконечные многочисленные и многостраничные, устаревающие уже в процессе создания, рисунки моделей, «макулатуру» со схемами, оторванные как от реальной жизни так и от реальных программных систем, написанных программистами? 61... [стр. 59 ⇒]