WikiDer > Объектно-ориентированного программирования

Object-oriented programming
«Объектно-ориентированный» перенаправляет сюда. О других значениях объектно-ориентированного см. Объектная ориентация.
«Объектно-ориентированный язык программирования» перенаправляется сюда. Список объектно-ориентированных языков программирования см. Список объектно-ориентированных языков программирования.

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

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

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

Многие из наиболее широко используемых языков программирования (например, C ++, Java, Python и т. Д.) Являются мультипарадигма и они в большей или меньшей степени поддерживают объектно-ориентированное программирование, обычно в сочетании с императив, процедурное программирование. Важные объектно-ориентированные языки включают: (порядок списков на основе Индекс TIOBE)Ява,C ++,C #,Python,р,PHP,Visual Basic.NET,JavaScript,Рубин,Perl,Object Pascal,Цель-C,Дротик,Быстрый,Scala,Котлин,Common Lisp,MATLAB,иБолтовня.

Функции

В объектно-ориентированном программировании используются объекты, но не все связанные методы и структуры поддерживаются напрямую на языках, которые утверждают, что поддерживают ООП. Перечисленные ниже функции являются общими для языков, которые считаются строго классовыми и объектно-ориентированными (или мультипарадигма с поддержкой ООП), с упомянутыми заметными исключениями.[3][4][5][6]

Смотрите также: Сравнение языков программирования (объектно-ориентированное программирование) и Список терминов объектно-ориентированного программирования

Совместно с языками без ООП

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

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

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

  • Классы - определения формата данных и доступных процедур для данного типа или класса объекта; могут также содержать сами данные и процедуры (известные как методы класса), т.е. классы содержат элементы данных и функции-члены
  • Объекты - экземпляры классов

Иногда объекты соответствуют вещам, которые можно найти в реальном мире. Например, графическая программа может иметь такие объекты, как «круг», «квадрат», «меню». Система покупок в Интернете может иметь такие объекты, как «корзина», «покупатель» и «продукт».[7] Иногда объекты представляют собой более абстрактные сущности, такие как объект, представляющий открытый файл, или объект, который предоставляет услугу перевода измерений из общепринятых в США в метрики.

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

Джунад Али, Освоение шаблонов проектирования PHP[8]

Каждый объект называется пример определенного класса (например, объект с полем его имени, установленным на "Мэри", может быть экземпляром класса Employee). Процедуры в объектно-ориентированном программировании известны как методы; переменные также известны как поля, члены, атрибуты или свойства. Это приводит к следующим условиям:

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

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

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

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

На основе классов и на основе прототипов

В классы на основе языков то классы определены заранее, а объекты создаются на основе классов. Если два объекта яблоко и апельсин создаются из класса Фрукты, они по своей сути являются фруктами, и вы гарантированно сможете обращаться с ними таким же образом; например программист может ожидать существования таких же атрибутов, как цвет или же сахар_содержание или же is_ripe.

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

Динамическая отправка / передача сообщений

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

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

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

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

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

Состав, наследование и делегирование

Объекты могут содержать другие объекты в своих переменных экземпляра; это известно как состав объекта. Например, объект в классе Employee может содержать (напрямую или через указатель) объект в классе Address в дополнение к своим собственным переменным экземпляра, таким как «first_name» и «position». Композиция объектов используется для представления отношений типа «есть-а»: у каждого сотрудника есть адрес, поэтому каждый объект Employee имеет доступ к месту для хранения объекта Address (либо непосредственно встроенного в себя, либо в отдельном месте, адресуемом через указатель) .

Языки, поддерживающие классы, почти всегда поддерживают наследование. Это позволяет классам быть организованными в иерархию, которая представляет отношения типа «есть тип». Например, класс Employee может быть унаследован от класса Person. Все данные и методы, доступные для родительского класса, также появляются в дочернем классе с такими же именами. Например, класс Person может определять переменные first_name и last_name с помощью метода make_full_name (). Они также будут доступны в классе Employee, который может добавлять переменные «должность» и «зарплата». Этот метод позволяет легко повторно использовать одни и те же процедуры и определения данных в дополнение к потенциально интуитивному отображению реальных отношений. Вместо того, чтобы использовать таблицы базы данных и подпрограммы программирования, разработчик использует объекты, с которыми пользователь может быть более знаком: объекты из области их приложения.[9]

Подклассы могут переопределять методы, определенные суперклассами. Множественное наследование разрешено на некоторых языках, хотя это может усложнить разрешение переопределений. Некоторые языки имеют специальную поддержку миксины, хотя на любом языке с множественным наследованием миксин - это просто класс, который не представляет отношения типа «есть тип». Миксины обычно используются для добавления одних и тех же методов к нескольким классам. Например, класс UnicodeConversionMixin может предоставлять метод unicode_to_ascii () при включении в класс FileReader и класс WebPageScraper, которые не имеют общего родителя.

Абстрактные классы не может быть инстанцирован в объекты; они существуют только с целью наследования в другие «конкретные» классы, которые могут быть созданы. В Java окончательный ключевое слово может использоваться для предотвращения разделения класса на подклассы.

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

"открытый / закрытый принцип«выступает за то, чтобы классы и функции» были открыты для расширения, но закрыты для модификации ».

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

Полиморфизм

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

Например, объекты типа Circle и Square являются производными от общего класса Shape. Функция Draw для каждого типа Shape реализует то, что необходимо для рисования самого себя, в то время как вызывающий код может оставаться безразличным к конкретному типу рисуемого Shape.

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

Открытая рекурсия

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

История

UML обозначение класса. Этот класс Button имеет переменные для данных и функции. Посредством наследования подкласс может быть создан как подмножество класса Button. Объекты - это экземпляры класса.

Терминология «объекты» и «ориентированный» в современном смысле объектно-ориентированного программирования впервые появилась на Массачусетский технологический институт в конце 1950-х - начале 1960-х гг. В среде искусственный интеллект группа, еще в 1960 году "объект" мог относиться к идентифицированным объектам (LISP атомы) со свойствами (атрибутами);[10][11]Алан Кей Позже в 1966 году он упомянул подробное понимание внутреннего устройства LISP, оказавшее сильное влияние на его мышление.[12]

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

Алан Кей, [12]

Другой ранний пример MIT был Блокнот сделано Иван Сазерленд в 1960–61 гг .; В глоссарии технического отчета 1963 года, основанного на его диссертации о Sketchpad, Сазерленд определил понятия «объект» и «экземпляр» (с концепцией класса, охватываемой «хозяином» или «определением»), хотя и специализированными на графическом взаимодействии.[13]Кроме того, Массачусетский технологический институт АЛГОЛ версия, AED-0, установила прямую связь между структурами данных (на этом диалекте «сплетениями») и процедурами, предвосхищая то, что позже было названо «сообщениями», «методами» и «функциями-членами».[14][15]

В 1962 г. Кристен Найгаард инициировал проект языка моделирования в Норвежский вычислительный центр, основываясь на его предыдущем использовании Моделирование Монте-Карло и его работа по концептуализации систем реального мира. Оле-Йохан Даль официально присоединился к проекту и Симула язык программирования был разработан для работы на Универсальный автоматический компьютер (UNIVAC) 1107. Simula представила важные концепции, которые сегодня являются важной частью объектно-ориентированного программирования, такие как учебный класс и объект, наследование и динамическое связывание.[16] Simula также была разработана с учетом программирования и безопасность данных. В целях безопасности программирования процесс обнаружения был реализован таким образом, чтобы через количество ссылок последнее средство уборщик мусора удалил неиспользуемые объекты в оперативная память (БАРАН). Но хотя идея объектов данных уже сформировалась к 1965 году, инкапсуляция данных через уровни охвата за переменные, такие как private (-) и public (+), не были реализованы в Simula, потому что это потребовало бы скрытия процедур доступа.[17]

На ранних стадиях Simula должна была быть пакетом процедур для языка программирования. АЛГОЛ 60. Неудовлетворенные ограничениями, налагаемыми ALGOL, исследователи решили развить Simula в полноценный язык программирования, в котором использовался компилятор UNIVAC ALGOL 60. Simula продвигалась Далем и Найгаардом на протяжении 1965 и 1966 годов, что привело к увеличению использования языка программирования в Швеции, Германии и других странах. Советский союз. В 1968 году язык стал широко доступным благодаря Компьютеры Burroughs B5500, а позже был реализован на ЭВМ УРАЛ-16. В 1966 году Даль и Найгаард написали Simula компилятор. Они были озабочены применением на практике Тони Хоарконцепция класса записи, которая была реализована в свободной форме, англоязычном языке моделирования общего назначения SIMSCRIPT. Они остановились на обобщенной концепции процесса со свойствами класса записи и вторым уровнем префиксов. Посредством префикса процесс может ссылаться на своего предшественника и иметь дополнительные свойства. Таким образом, Simula представила иерархию классов и подклассов, а также возможность создания объектов из этих классов.

Компилятор Simula 67 был запущен для Система / 360 и Система / 370 Мэйнфреймы IBM в 1972 г.[16] В том же году компилятор Simula 67 был запущен бесплатно для французского языка. CII 10070 и CII Ирис 80 мэйнфреймы. К 1974 году в Ассоциацию пользователей Simula входили члены из 23 разных стран. В начале 1975 года компилятор Simula 67 был выпущен бесплатно для DECsystem-10 семейство мэйнфреймов. К августу того же года компилятор DECsystem-10 Simula 67 был установлен на 28 сайтах, 22 из которых в Северной Америке. Объектно-ориентированный язык программирования Simula использовался в основном исследователями, занимающимися физическое моделирование, например, модели для изучения и улучшения движения судов и их содержимого через грузовые порты.[16]

В 1970-х годах первая версия Болтовня язык программирования был разработан в Xerox PARC к Алан Кей, Дэн Ингаллс и Адель Голдберг. Smaltalk-72 включал среду программирования и был динамически типизированный, и сначала было интерпретированный, нет составлен. Smalltalk стал известен своим применением объектной ориентации на уровне языка и графической средой разработки. Smalltalk прошел через различные версии, и интерес к языку рос.[18] Хотя на Smalltalk повлияли идеи, представленные в Simula 67, он был разработан как полностью динамическая система, в которой классы можно было создавать и изменять динамически.[19]

В 1970-х годах Smalltalk повлиял на Сообщество Lisp включить объектно-ориентированные методы которые были представлены разработчикам через Лисп-машина. Эксперименты с различными расширениями Lisp (такими как LOOPS и Ароматизаторы введение множественное наследование и миксины) в итоге привело к Общая объектная система Lisp, который объединяет функциональное программирование и объектно-ориентированное программирование и допускает расширение через Мета-объектный протокол. В 1980-х годах было несколько попыток разработать архитектуры процессоров, которые включали бы аппаратную поддержку объектов в памяти, но они не увенчались успехом. Примеры включают Intel iAPX 432 и Линн Смарт Рекурсив.

В 1981 году Голдберг отредактировал августовский выпуск журнала 1981 года. Журнал Byte, знакомство с Smalltalk и объектно-ориентированным программированием широкой аудитории. В 1986 г. Ассоциация вычислительной техники организовал первый Конференция по объектно-ориентированному программированию, системам, языкам и приложениям (OOPSLA), на котором неожиданно присутствовало 1000 человек. В середине 1980-х гг. Цель-C был разработан Брэд Кокс, который использовал Smalltalk в ITT Inc., и Бьярне Страуструп, который использовал Simula для своей докторской диссертации, в конечном итоге пошел на создание объектно-ориентированного C ++.[18] В 1985 г. Бертран Мейер также произвел первый дизайн Эйфелева язык. Ориентированный на качество программного обеспечения, Eiffel - это чисто объектно-ориентированный язык программирования и нотация, поддерживающая весь жизненный цикл программного обеспечения. Мейер описал метод разработки программного обеспечения Eiffel, основанный на небольшом количестве ключевых идей из программной инженерии и информатики, в Построение объектно-ориентированного программного обеспечения. Важнейшим фактором качества Eiffel является механизм надежности Майера, Дизайн по контракту, который является неотъемлемой частью как метода, так и языка.

В TIOBE индекс популярности языков программирования график с 2002 по 2018 год. В 2000-х объектно-ориентированные Ява (синий) и процедурный C (черный) боролись за первое место.

В начале и середине 1990-х объектно-ориентированное программирование развивалось как доминирующее направление программирования. парадигма когда языки программирования, поддерживающие эти методы, стали широко доступны. К ним относятся Visual FoxPro 3.0,[20][21][22] C ++,[23] и Delphi[нужна цитата]. Его доминирование было усилено растущей популярностью графический пользовательский интерфейс, которые в значительной степени опираются на методы объектно-ориентированного программирования. Пример тесно связанной библиотеки динамического графического интерфейса и языка ООП можно найти в Какао рамки на Mac OS X, написано в Цель-C, объектно-ориентированное расширение динамического обмена сообщениями для C на основе Smalltalk. Наборы инструментов ООП также повысили популярность событийно-ориентированное программирование (хотя это понятие не ограничивается ООП).

В ETH Zürich, Никлаус Вирт и его коллеги также исследовали такие темы, как абстракция данных и модульное программирование (хотя это было широко распространено в 1960-х годах или раньше). Модула-2 (1978) включили оба и их последующий дизайн, Оберон, включал особый подход к объектной ориентации, классам и т. д.

Объектно-ориентированные функции были добавлены ко многим ранее существовавшим языкам, включая Ада, БАЗОВЫЙ, Фортран, Паскаль, и КОБОЛ. Добавление этих функций к языкам, которые изначально не были предназначены для них, часто приводило к проблемам с совместимостью и ремонтопригодностью кода.

Совсем недавно появился ряд языков, которые в основном объектно-ориентированы, но также совместимы с процедурной методологией. Два таких языка Python и Рубин. Вероятно, наиболее коммерчески важными современными объектно-ориентированными языками являются: Ява, разработан Sun Microsystems, а также C # и Visual Basic.NET (VB.NET), оба предназначены для Microsoft .СЕТЬ Платформа. Каждая из этих двух структур по-своему демонстрирует преимущества использования ООП, создавая абстракцию от реализации. VB.NET и C # поддерживают межъязыковое наследование, позволяя классам, определенным на одном языке, создавать подклассы, определенные на другом языке.

ООП языки

Смотрите также: Список объектно-ориентированных языков программирования

Симула (1967) обычно считается первым языком с основными характеристиками объектно-ориентированного языка. Он создан для того, чтобы программы моделирования, в котором то, что стало называться объектами, было наиболее важным представлением информации. Болтовня (1972–1980) - еще один ранний пример, на основе которого была разработана большая часть теории ООП. Что касается степени объектной ориентации, можно выделить следующие различия:

  • Языки называются "чистыми" объектно-ориентированными языками, потому что все в них последовательно обрабатывается как объект, от примитивов, таких как символы и знаки препинания, до целых классов, прототипов, блоков, модулей и т. Д. Они были разработаны специально для облегчения, даже применять ОО-методы. Примеры: Рубин, Scala, Болтовня, Эйфель, Изумруд,[24] ДЖЕЙД, Себя, Раку.
  • Языки, предназначенные в основном для объектно-ориентированного программирования, но с некоторыми процедурными элементами. Примеры: Ява, Python, C ++, C #, Delphi / Object Pascal, VB.NET.
  • Языки, которые исторически процедурные языки, но были расширены некоторыми функциями объектно-ориентированного программирования. Примеры: PHP, Perl, Visual Basic (происходит от BASIC), MATLAB, COBOL 2002, Фортран 2003, ABAP, Ада 95, Паскаль.
  • Языки с большинством функций объектов (классы, методы, наследование), но в отчетливо оригинальной форме. Примеры: Оберон (Оберон-1 или Оберон-2).
  • Языки с абстрактный тип данных поддержка, которая может использоваться для напоминания объектно-ориентированного программирования, но без всех функций объектной ориентации. Это включает в себя объект-основан и на основе прототипа языков. Примеры: JavaScript, Lua, Модула-2, CLU.
  • Языки-хамелеоны, поддерживающие несколько парадигм, включая объектно-ориентированный. Tcl выделяется среди них TclOO, гибридной объектной системой, которая поддерживает как программирование на основе прототипов и объектно-ориентированный объект на основе классов.

ООП на динамических языках

В последние годы объектно-ориентированное программирование стало особенно популярным в языки динамического программирования. Python, PowerShell, Рубин и Groovy являются динамическими языками, построенными на принципах ООП, а Perl и PHP добавляли объектно-ориентированные функции начиная с Perl 5 и PHP 4, и Холодный синтез начиная с версии 6.

В Объектная модель документа из HTML, XHTML, и XML документы в Интернете привязаны к популярным JavaScript/ECMAScript язык. JavaScript, пожалуй, самый известный программирование на основе прототипов язык, который использует клонирование из прототипов, а не наследование от класса (в отличие от программирование на основе классов). Другой язык сценариев, использующий этот подход, - Lua.

ООП в сетевом протоколе

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

  • Поля, определяющие значения данных, которые формируют сообщения, такие как их длина, кодовая точка и значения данных.
  • Объекты и коллекции объектов, похожие на то, что можно найти в Болтовня программа для сообщений и параметров.
  • Менеджеры, похожие на Объекты AS / 400, например, каталог для файлов и файлов, состоящих из метаданных и записей. Менеджеры концептуально предоставляют память и ресурсы обработки для содержащихся в них объектов.
  • Клиент или сервер, состоящий из всех менеджеров, необходимых для реализации полной среды обработки, поддерживающей такие аспекты, как службы каталогов, безопасность и контроль параллелизма.

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

Шаблоны проектирования

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

Наследование и поведенческие подтипы

Смотрите также: Объектно-ориентированный дизайн

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

Банда четырех шаблонов проектирования

Основная статья: Шаблон проектирования (информатика)

Паттерны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования влиятельная книга, опубликованная в 1994 г. Эрих Гамма, Ричард Хелм, Ральф Джонсон, и Джон Влиссидес, которую с юмором часто называют «Бандой четырех». Наряду с исследованием возможностей и ловушек объектно-ориентированного программирования в нем описаны 23 распространенные проблемы программирования и шаблоны их решения. По состоянию на апрель 2007 года книга находилась в 36-м издании.

В книге описаны следующие шаблоны:

Объектная ориентация и базы данных

Основные статьи: Несоответствие объектно-реляционного импеданса, Объектно-реляционное отображение, и База данных объектов

И объектно-ориентированное программирование, и системы управления реляционными базами данных (СУБД) сегодня чрезвычайно распространены в программном обеспечении. С реляционные базы данных не храните объекты напрямую (хотя некоторые СУБД имеют объектно-ориентированные функции, приближающие это), существует общая потребность в соединении двух миров. Проблема связывания доступа объектно-ориентированного программирования и шаблонов данных с реляционными базами данных известна как объектно-относительное рассогласование импеданса. Есть несколько подходов к решению этой проблемы, но нет общего решения без недостатков.[25] Один из наиболее распространенных подходов - объектно-реляционное отображение, как найдено в IDE языки, такие как Visual FoxPro и библиотеки, такие как Объекты данных Java и Рубин на рельсах'ActiveRecord.

Это также объектные базы данных которые можно использовать для замены РСУБД, но они не были так технически и коммерчески успешны, как РСУБД.

Моделирование и отношения в реальном мире

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

Тем не мение, Никлаус Вирт (который популяризировал пословицу, теперь известную как Закон вирта: «Программное обеспечение становится медленнее, чем оборудование становится быстрее»), - сказал о ООП в своей статье «Хорошие идеи в Зазеркалье»: «Эта парадигма точно отражает структуру систем« в реальном мире », и поэтому хорошо подходит для моделирования сложных систем со сложным поведением "[28] (контраст Принцип KISS).

Стив Егге и другие отметили, что естественным языкам не хватает подхода ООП со строгим приоритетом вещи (объекты/существительные) перед действия (методы /глаголы).[29] Эта проблема может привести к тому, что ООП столкнется с более сложными решениями, чем процедурное программирование.[30]

ООП и поток управления

ООП был разработан для увеличения возможность повторного использования и ремонтопригодность исходного кода.[31] Прозрачное представление поток управления не имел приоритета и предназначался для обработки компилятором. С ростом актуальности параллельного оборудования и многопоточное кодирование, разработка прозрачного потока управления становится все более важной, чего трудно достичь с помощью ООП.[32][33][34][35]

Ответственность против дизайна, основанного на данных

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

Рекомендации по SOLID и GRASP

ТВЕРДЫЙ - это мнемоника, изобретенная Майклом Фезерсом, которая представляет и поддерживает пять практик программирования:

ПОНЯТЬ (Шаблоны программного обеспечения для распределения общей ответственности) - это еще один набор рекомендаций, рекомендуемых Крейг Ларман.

Критика

Парадигма ООП подвергалась критике по ряду причин, включая несоответствие заявленным целям повторного использования и модульности,[36][37] и для чрезмерного акцента на одном аспекте проектирования и моделирования программного обеспечения (данные / объекты) за счет других важных аспектов (вычислений / алгоритмов).[38][39]

Лука Карделли утверждал, что код ООП «по своей сути менее эффективен», чем процедурный код, что ООП может потребовать больше времени для компиляции, и что языки ООП имеют «крайне плохие свойства модульности в отношении расширения и модификации классов» и имеют тенденцию быть чрезвычайно сложными.[36] Последний пункт повторяется Джо Армстронг, главный изобретатель Erlang, который цитируется:[37]

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

Исследование Potok et al. не показал существенной разницы в производительности между ООП и процедурными подходами.[40]

Кристофер Дж. Дат заявил, что критическое сравнение ООП с другими технологиями, в частности реляционными, затруднительно из-за отсутствия согласованного и строгого определения ООП;[41] однако Дэйт и Дарвен предложили теоретическую основу ООП, которая использует ООП как своего рода настраиваемый система типов поддерживать СУБД.[42]

В статье Лоуренс Крубнер утверждал, что по сравнению с другими языками (диалектами LISP, функциональными языками и т. Д.) ООП-языки не обладают уникальными сильными сторонами и создают тяжелое бремя ненужной сложности.[43]

Александр Степанов неблагоприятно сравнивает ориентацию объекта с общее программирование:[38]

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

Пол Грэм предположил, что популярность ООП в крупных компаниях обусловлена ​​«большой (и часто меняющейся) группой посредственных программистов». По словам Грэма, дисциплина, налагаемая ООП, не позволяет любому программисту «нанести слишком большой урон».[44]

Лео Броди предположил связь между автономной природой объектов и склонностью к повторяющийся код[45] в нарушение не повторяйся принцип[46] разработки программного обеспечения.

Стив Егге отметил, что в отличие от функциональное программирование:[47]

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

Рич Хикки, создатель Clojure, описал объектные системы как чрезмерно упрощенные модели реального мира. Он подчеркнул неспособность ООП правильно моделировать время, что становится все более проблематичным по мере того, как программные системы становятся более параллельными.[39]

Эрик С. Раймонд, а Unix программист и программное обеспечение с открытым исходным кодом выступил с критикой заявлений о том, что объектно-ориентированное программирование является «единым истинным решением», и писал, что объектно-ориентированные языки программирования, как правило, поощряют многослойные программы, разрушающие прозрачность.[48] Раймонд сравнивает это неблагоприятно с подходом, принятым с Unix и Язык программирования C.[48]

Роб Пайк, программист, участвовавший в создании UTF-8 и Идти, назвал объектно-ориентированное программирование " римские цифры вычислительной техники "[49] и сказал, что языки ООП часто смещают акцент с структуры данных и алгоритмы к типы.[50] Furthermore, he cites an instance of a Ява professor whose "idiomatic" solution to a problem was to create six new classes, rather than to simply use a Справочная таблица.[51]

Формальная семантика

Смотрите также: Формальная семантика языков программирования

Objects are the run-time entities in an object-oriented system. They may represent a person, a place, a bank account, a table of data, or any item that the program has to handle.

There have been several attempts at formalizing the concepts used in object-oriented programming. The following concepts and constructs have been used as interpretations of OOP concepts:

Attempts to find a consensus definition or theory behind objects have not proven very successful (however, see Abadi & Cardelli, A Theory of Objects[53] for formal definitions of many OOP concepts and constructs), and often diverge widely. For example, some definitions focus on mental activities, and some on program structuring. One of the simpler definitions is that OOP is the act of using "map" data structures or arrays that can contain functions and pointers to other maps, all with some syntactic and scoping sugar наверху. Inheritance can be performed by cloning the maps (sometimes called "prototyping").

Смотрите также

Системы

Языки моделирования

Рекомендации

  1. ^ Kindler, E .; Кривой, И. (2011). «Объектно-ориентированное моделирование систем со сложным управлением». Международный журнал общих систем: 313–343. Цитировать журнал требует | журнал = (помощь)
  2. ^ Льюис, Джон; Лофтус, Уильям (2008). Программные решения Java. Основы проектирования программирования. 6-е изд.. Pearson Education Inc. ISBN 978-0-321-53205-3., раздел 1.6 «Объектно-ориентированное программирование»
  3. ^ Deborah J. Armstrong. The Quarks of Object-Oriented Development. A survey of nearly 40 years of computing literature which identified a number of fundamental concepts found in the large majority of definitions of OOP, in descending order of popularity: Inheritance, Object, Class, Encapsulation, Method, Message Passing, Polymorphism, and Abstraction.
  4. ^ Джон С. Митчелл, Concepts in programming languages, Cambridge University Press, 2003 г., ISBN 0-521-78098-5, с.278. Lists: Dynamic dispatch, abstraction, subtype polymorphism, and inheritance.
  5. ^ Майкл Ли Скотт, Прагматика языка программирования, Издание 2, Морган Кауфманн, 2006 г., ISBN 0-12-633951-1, п. 470. Lists encapsulation, inheritance, and dynamic dispatch.
  6. ^ Пирс, Бенджамин (2002). Типы и языки программирования. MIT Press. ISBN 978-0-262-16209-8., section 18.1 "What is Object-Oriented Programming?" Lists: Dynamic dispatch, encapsulation or multi-methods (multiple dispatch), subtype polymorphism, inheritance or delegation, open recursion ("this"/"self")
  7. ^ Booch, Grady (1986). Разработка программного обеспечения с помощью Ada. Эддисон Уэсли. п. 220. ISBN 978-0805306088. Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world.
  8. ^ Ali, Junade (28 September 2016). Освоение шаблонов проектирования PHP | PACKT Книги (1-е изд.). Бирмингем, Англия, Великобритания: Packt Publishing Limited. п. 11. ISBN 978-1-78588-713-0. Получено 11 декабря 2017.
  9. ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. стр.43–69. ISBN 978-0-201-54435-0.
  10. ^ McCarthy, J .; Brayton, R.; Edwards, D.; Fox, P.; Hodes, L.; Luckham, D.; Maling, K.; Park, D.; Russell, S. (Март 1960 г.). "LISP I Programmers Manual" (PDF). Бостон, Массачусетс: Artificial Intelligence Group, M.I.T. Computation Center и Исследовательская лаборатория: 88f. Архивировано из оригинал (PDF) 17 июля 2010 г. In the local M.I.T. patois, association lists [of atomic symbols] are also referred to as "property lists", and atomic symbols are sometimes called "objects". Цитировать журнал требует | журнал = (помощь)
  11. ^ Маккарти, Джон; Abrahams, Paul W.; Edwards, Daniel J.; Hart, swapnil d.; Levin, Michael I. (1962). LISP 1.5 Programmer's Manual. MIT Press. п.105. ISBN 978-0-262-13011-0. Object — a synonym for atomic symbol
  12. ^ а б "Dr. Alan Kay on the Meaning of "Object-Oriented Programming"". 2003. Получено 11 февраля 2010.
  13. ^ Sutherland, I. E. (30 January 1963). "Sketchpad: A Man-Machine Graphical Communication System". Technical Report No. 296, Lincoln Laboratory, Massachusetts Institute of Technology via Defense Technical Information Center (stinet.dtic.mil). Получено 17 июля 2019.
  14. ^ The Development of the Simula Languages, Кристен Найгаард, Оле-Йохан Даль, p.254 Uni-kl.ac.at
  15. ^ Ross, Doug. "The first software engineering language". LCS/AI Lab Timeline. Лаборатория компьютерных наук и искусственного интеллекта Массачусетского технологического института. Получено 13 мая 2010.
  16. ^ а б c Holmevik, Jan Rune (1994). "Compiling Simula: A historical study of technological genesis" (PDF). IEEE Annals of the History of Computing. 16 (4): 25–37. Дои:10.1109/85.329756. Получено 3 марта 2018.
  17. ^ Dahl, Ole Johan (2004). "The Birth of Object Orientation: The Simula Languages" (PDF). From Object-Orientation to Formal Methods. Конспект лекций по информатике. 2635. С. 15–25. CiteSeerX 10.1.1.133.6730. Дои:10.1007/978-3-540-39993-3_3. ISBN 978-3-540-21366-6. Получено 3 марта 2018.
  18. ^ а б Бертран Мейер (2009). Touch of Class: учимся хорошо программировать с объектами и контрактами. Springer Science & Business Media. п. 329. Bibcode:2009tclp.book.....M. ISBN 9783540921448.
  19. ^ Kay, Alan. «Ранняя история Smalltalk». Архивировано из оригинал 10 июля 2008 г.. Получено 13 сентября 2007.
  20. ^ 1995 (June) Visual FoxPro 3.0, FoxPro evolves from a procedural language to an object-oriented language. Visual FoxPro 3.0 introduces a database container, seamless client/server capabilities, support for ActiveX technologies, and OLE Automation and null support. Summary of Fox releases
  21. ^ FoxPro History web site: Foxprohistory.org
  22. ^ 1995 Reviewers Guide to Visual FoxPro 3.0: DFpug.de
  23. ^ Khurana, Rohit (1 November 2009). Object Oriented Programming with C++, 1E. ISBN 9788125925323.
  24. ^ "The Emerald Programming Language". 26 февраля 2011 г.
  25. ^ Neward, Ted (26 June 2006). "The Vietnam of Computer Science". Interoperability Happens. Архивировано из оригинал 4 июля 2006 г.. Получено 2 июн 2010.
  26. ^ Meyer, Second Edition, p. 230
  27. ^ M.Trofimov, OOOP – The Third "O" Solution: Open OOP. First Class, мой Бог, 1993, т. 3, issue 3, p.14.
  28. ^ Wirth, Nicklaus (2006). «Хорошие идеи в Зазеркалье» (PDF). Компьютер. 39 (1): 28–39. Дои:10.1109/mc.2006.20. Получено 2 октября 2016.
  29. ^ Yegge, Steve (30 March 2006). "Execution in the Kingdom of Nouns". steve-yegge.blogspot.com. Получено 3 июля 2010.
  30. ^ Boronczyk, Timothy (11 June 2009). "What's Wrong with OOP". zaemis.blogspot.com. Получено 3 июля 2010.
  31. ^ Ambler, Scott (1 January 1998). "A Realistic Look at Object-Oriented Reuse". drdobbs.com. Получено 4 июля 2010.
  32. ^ Shelly, Asaf (22 August 2008). "Flaws of Object Oriented Modeling". Intel Software Network. Получено 4 июля 2010.
  33. ^ James, Justin (1 October 2007). "Multithreading is a verb not a noun". techrepublic.com. Архивировано из оригинал 10 октября 2007 г.. Получено 4 июля 2010.
  34. ^ Shelly, Asaf (22 August 2008). "HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions". support.microsoft.com. Получено 4 июля 2010.
  35. ^ Роберт Харпер (17 April 2011). "Some thoughts on teaching FP". Existential Type Blog. Получено 5 декабря 2011.
  36. ^ а б Карделли, Лука (1996). "Bad Engineering Properties of Object-Oriented Languages". ACM Comput. Surv. 28 (4es): 150–es. Дои:10.1145/242224.242415. ISSN 0360-0300. Получено 21 апреля 2010.
  37. ^ а б Армстронг, Джо. В Кодеры за работой: размышления о ремесле программирования. Peter Seibel, ed. Codersatwork.com, Accessed 13 November 2009.
  38. ^ а б Stepanov, Alexander. "STLport: An Interview with A. Stepanov". Получено 21 апреля 2010.
  39. ^ а б Rich Hickey, JVM Languages Summit 2009 keynote, Мы уже на месте? Ноябрь 2009 г.
  40. ^ Potok, Thomas; Mladen Vouk; Andy Rindos (1999). "Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment" (PDF). Программное обеспечение - практика и опыт. 29 (10): 833–847. Дои:10.1002/(SICI)1097-024X(199908)29:10<833::AID-SPE258>3.0.CO;2-P. Получено 21 апреля 2010.
  41. ^ C. J. Date, Introduction to Database Systems, 6th-ed., Page 650
  42. ^ C. J. Date, Hugh Darwen. Foundation for Future Database Systems: The Third Manifesto (2-е издание)
  43. ^ Krubner, Lawrence. "Object Oriented Programming is an expensive disaster which must end". smashcompany.com. Архивировано из оригинал 14 октября 2014 г.. Получено 14 октября 2014.
  44. ^ Грэм, Пол. "Why ARC isn't especially Object-Oriented". PaulGraham.com. Получено 13 ноября 2009.
  45. ^ Броди, Лео (1984). Думая дальше (PDF). стр. 92–93. Получено 4 мая 2018.
  46. ^ Hunt, Andrew. "Don't Repeat Yourself". Category Extreme Programming. Получено 4 мая 2018.
  47. ^ "Stevey's Blog Rants: Execution in the Kingdom of Nouns". Получено 20 мая 2020.
  48. ^ а б Eric S. Raymond (2003). "The Art of Unix Programming: Unix and Object-Oriented Languages". Получено 6 августа 2014.
  49. ^ Пайк, Роб (2 March 2004). "[9fans] Re: Threads: Sewing badges of honor onto a Kernel". comp.os.plan9 (Список рассылки). Получено 17 ноября 2016.
  50. ^ Pike, Rob (25 June 2012). "Меньше значит экспоненциально больше". Получено 1 октября 2016.
  51. ^ Pike, Rob (14 November 2012). "A few years ago I saw this page". Архивировано из оригинал 14 августа 2018 г.. Получено 1 октября 2016.
  52. ^ Poll, Erik. "Subtyping and Inheritance for Categorical Datatypes" (PDF). Получено 5 июн 2011.
  53. ^ а б Abadi, Martin; Cardelli, Luca (1996). A Theory of Objects. Springer-Verlag New York, Inc. ISBN 978-0-387-94775-4. Получено 21 апреля 2010.

дальнейшее чтение

внешняя ссылка

{{Navboxf|title = Типы языков программирования|listclass = hlist

| group1= Paradigm|list1 =

|group3 = Level|list3 =

|group4 = Generation|list4 =

|group5 = Related|list5 =

}}