Парадигмы программирования

21 век - объектно-ориентированное

программирование (ООП).

За какие-то 15 лет оно воплотилось

в господствующую религию,

подчинившую умы миллионов

программистов.

ООП - стандарт де-факто.

С использованием объектноориентированной методологии

(ООМ) осуществляется разработка

огромного числа программных

проектов, а ООП является

основным инструментом для

построения кода. 1

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

Наиболее известным инструментом проектирования является Rational Rose.

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

ООП программирование Объектно-ориентированное программирование (ООП) — парадигма программирования, основанная на представлении предметной области (и/или проблемной области) в виде информационных моделей на основе системы взаимосвязанных абстрактных объектов и их реализаций.

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

Это вносило некоторую сложность в разработку программы. С появлением концепции ООП появилась новая структура «произвольных» данных — Класс.

ООП программирование Это по сути дела тип данных, внешне похожий на структуру (в языке Си) или запись (в Pascal-е), в котором кроме данных (свойства) также содержались функции их обработки (методы).

При этом появляются такие свойства как наследование, полиморфизм и инкапсуляция.

ООП программирование Объектно-ориентированная парадигма программирования не нова. Е истоки восходят к Симуле-67, хотя первая полная реализация была в Smalltalk-80.

ООП стало популярным во второй половине 80-х в таких различных языках, как Си-плюс-плюс, Objective C (другое расширение C), Object и Турбо Паскаль, CLOS (ОО-расширение Лиспа), Eiffel, Ада (в е последних воплощениях) и недавно - в Яве.

Эта работа сосредоточена на Си-плюс-плюс, в Объектном Паскале и Яве, иногда упоминая и другие языки.

ООП программирование Ключевые черты ООП хорошо известны.

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

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

Это способствует выражению специализации и генерализации.

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

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

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

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

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

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

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

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

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

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

Объектно-ориентированные языки программирования С++ (расширение C) Delphi (расширение Pascal) MS Visual Basic (расширение Basic) Ada, Java, C#, Perl, Python, PHP и др.

Следует также отметить язык программирования Оберон-2, разработанный под руководством Н.

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

Фортран – далее APL (его название иногда расшифровывают как A Programming Language, но чаще Array Processing Language) (APL/360).

Функциональное программирование: SECD машины Ландин's (1964) IAL (International Algebraic Language) - Алгол 58.

Особый интерес представляет процедура разработки языка Алгол, которая привлекла к себе выдающихся ученых.

Поколению программистов, воспитанных на языках Си или Java, могут показаться странными те надежды, которые возлагались на языки лет 40 назад.

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

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

Другие языки Сегодня трудно сказать с полной уверенностью, что работы Хомского действительно серьезно повлияли на развитие языков программирования, но одно явное следствие, безусловно, есть — это нотация Бэкуса-Наура.

Джон Бэкус и Питер Наур разработали формальный метод описания языков программирования, приобретший популярность благодаря Алгол: любой учебник по этому языку включал описание на BNF.

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

Отсюда и аббревиатура JOVIAL (Jules Own Version of the International Algorithmic Language).

Долголетие это языка объясняется тем, что еще в 70-е годы Пентагон пришел к разумному решению о принятии стандарта на систему команд и архитектуру 16-разрядного микропроцессора для бортовых систем (кстати, стандарт MIL-STD-1750 действует в армии США по сей день). В качестве стандартного языка был избран JOVIAL, поскольку Шварц заложил в него возможность создания кросс­платформенных программ, способных работать в реальном режиме времени.

В структуре JOVIAL-машины имеются возможности оптимизации кода для переноса программ с компьютера, на котором ведется разработка, на целевой встроенный компьютер.

LISP (LISt Processing), изобретенный сотрудником Массачусетского технологического института Джоном Маккарти в 1958 году. Судьба языка LISP феноменальна, он активно использовался в исследованиях, связанных с искусственным интеллектом, вплоть до 90-х годов.

Потом интерес к нему ослабел, но начиная с 2000 года LISP снова на сцене, сегодня он в первой двадцатке по популярности.

LISP относят к числу языков, чей индекс популярности в наши дни растет наиболее быстро.

Последним в списке легендарных языков можно назвать Кобол, его история неоднократно описана, он был создан специальным комитетом Минобороны США всего за шесть месяцев. В его основу были положены идеи языков FLOWMATIC, изобретенного Грейс Хоппер, и COMTRAN Боба Бемера из IBM (последний более известен как один из авторов кода ASCII). Первая спецификация Кобол 60 была опубликована в 1960 году.

РЕФАЛ (РЕкурсивных Функций АЛгоритмический язык), изначально задуманный как метаязык для описания семантики других языков, но впоследствии, с появлением эффективных практических реализаций, он стал использоваться в качестве языка программирования.

ТеХ (Дональд Кнут) – технология проектирования и разработки ПО одновременно с докуметированием.

Декларативное программирование (LISP, РЕФАЛ, TeX).

Аксиоматическая семантика: Хор (1969) Логическое программирование: Absys Элкок's (1965), Пролог Colmerauer's (1972) Backtracking: Флойд (1967) Возможность безопасности: Деннис и Ван Хорн (1965) Декларативный параллелизма: Кан (1974) Передачи сообщений параллелизма: актер модели Хьюитт Последовавшая затем "кастрация" механизмов процедурного порождения программ привела к появлению новых, чисто объектных (как и Smalltalk) языков, тесно интегрированных с современной информационной средой.

Наиболее популярным из них оказался язык Java, ориентированный на кросс платформенную виртуальную машину, адаптированную к функционированию в среде Internet.

Поддерживаемая агрессивной маркетинговой политикой, ОО Java-технология заняла на рынке средств разработки одно из ведущих мест. А последним "писком" является C# - объектноориентированный кастрат от Microsoft в пику Java.

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

ОО "прибамбасы" существуют в Java Script, также и в VB Script.

На высоте оказался идиоматический Perl.

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

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

Наибольшего расцвета в "золотой век" процедурного подхода достигли структурное и функциональное программирование.

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

Наука информатика Приходится признать, что главная задача компьютерной науки — «не запутать все до неузнаваемости» — так и не была достигнута.

Увы, большинство наших систем слишком сложны, чтобы не тревожиться об их состоянии, они слишком хаотичны и запутаны, чтобы с ними можно было чувствовать себя уверенно и спокойно.

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

Жизненный цикл Обоснование требований Спецификации Кодирование Тестирование Внедрение Сопровождение Упадок структурного программирования Самый ощутимый удар был нанесен по структурному программированию (являющемуся в свое время наиболее популярным методом разработки программ).

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

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

Упадок структурного программирования Появились отдельные методики разработки структур данных и средств управления программой, а также методы обеспечивающие формирования кода по разработанным структурам данных. Ясная логическая структура управляющих примитивов привела к созданию методов доказательства правильности программ [Дейкстра].

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

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

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

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

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

Встраивание обработчика внутрь класса и возможность его переопределения в наследниках позволили локализовать проблему.

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

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

Упадок функционального программирования Функциональное программирование тоже опирается на процедурный подход.

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

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

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

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

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

Основная причина этой ситуации лежит в том, что, по своей сути, параллельное программирование это взаимодействие процессов.

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

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

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

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

Именно теория позволила создать нетрадиционные языки параллельного программирования, ряд из которых нашли практическое применение.

Упадок параллельного программирования Вместе с тем, популярность и распространенность языков параллельного программирования сильно зависели от текущего положения дел на рынке архитектур параллельных вычислительных систем.

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

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

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

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

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

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

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

Технологии программирования Баз Данных (Информационных Систем) – что такое ОБЪЕКТ?

На сегодняшний день в программировании не существует точной формулировки понятия объект!

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

Диапазон широк, от общефилософской "Все есть объект" (значит и стул, на котором сидит программист, тоже объект программирования), до слишком ограничивающих формулировок, например, в ООП объект наделяют обязательным свойством наследования. Некоторые формулировки просто устарели, хотя находятся в постоянном употреблении, например, утверждение о том, что объект должен находиться в оперативной памяти компьютера (тогда как быть с объектами, расположенными в БД?).

Парадигмы программирования Что такое ОБЪЕКТ:

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

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

ООП программирование Изменения в представлениях программистов вызваны с появлением сетевых технологий, WWW, WWW программирования и идеологии распределенных информационно-вычислительных систем (GRID).

ПРОЦЕССЫ на смену ОБЪЕКТОВ Парадигмы программирования Казалось бы, что такого в ООП? Ну, свалили в одну упаковку данные и процедуры, а потом начали обертывать этой "бумажкой" экземпляры коробок и использовать для доступа к содержимому название коробки.

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

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

Сравним жизненные циклы класса и элементарного процесса.

Их практическая эквивалентность говорит о том, что процесс может делать все то же, что и класс.

А уж сымитировать с его помощью модель класса - вообще нет проблем. При этом процесс, в общем случае, обеспечивает такую динамику поведения, которая не "снилась" ни одному другому программному объекту (достаточно почитать классиков [Хоар]).

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

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

Не вдаваясь в особенности синтаксиса и семантики этого языка, рассмотри пример фрагментов кода (кто хоть немного знает C++, тот поймет: Пример кода на РР.pdf Парадигмы программирования Возникает вопрос: во что выльется техническая реализация таких процессов и возможна ли она?

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

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

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

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

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

Перефразируя одну печально известную фразу можно сказать: "Оставь сомнения всяк, в процесс входящий"!

Парадигмы программирования Множество точек входов и ранее встречалось, даже в процедурах. Достаточно вспомнить PL/1 или Фортран. А реализация оболочки процесса может быть такой же, как и у компонента используемого в COM.

Эта двоичная оболочка, фиксирующая только указатель на таблицу функций, позволяет интерпретировать себя как угодно. Кстати, большинство реализаций класса используют точно такую же структуру.

Поэтому, вряд ли у процессов возникнут проблемы с инкапсуляцией, полиморфизмом и наследованием.

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

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

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

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

Алгоритмическая декомпозиция позволяет учитывать модель состояний, если опирается на декомпозицию процессов. И в перспективе она может использовать инкапсуляцию, наследование и полиморфизм.

Поэтому, вряд ли стоит ставить крест на структурном анализе и проектировании, начинающемся с описания бизнес процессов.

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

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

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

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

Только идиоты, политики и менеджеры могут создавать методологии, которые не используют выразительные возможности языков. Вряд ли можно отнести Буча к первым двум категориям. Это голова и гигант мысли в одном флаконе! Следовательно, он немного перестарался, чтобы раскрутить свои методы.

Хотя, и политики в программировании более чем достаточно.

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

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

Не отрицаю полезность накопленного эмпирического опыта и с удовольствием использую его в своей практике. Но, вместе с тем, создается впечатление, что мы пользуемся не той системой отсчета.

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

Я не думаю, что в мгновение ока поставлю в центр нашей системы Солнце. Скорее всего, у меня на этом месте расположится Марс.

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

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

Однако и в этой ситуации реализация остается прежней.

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

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

Любые внутренние изменения данных в процессах никоим образом не влияли на их взаимодействие.

Парадигмы программирования Так что, интерфейс - это не только процедуры. Он может быть выстроен и на основе модели данных.

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

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