Базовое понятие в объектно ориентированном программировании которое рассматривается как тип данных

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

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

них основаны на классах, что означает . Что объекты являются экземплярами классов, которые также определяют их типы.

Многие из наиболее широко используемых языков программирования (например, C++, Java. Python и т. Д.) Являются многопарадигмальными и в большей или меньшей степени поддерживают объектно-ориентированное программирование. Обычно в сочетании с императивнымпроцедурным программированием. Значительное объектно-ориентированные языки относятся: (перечислить порядка. Основанного на индексе TIOBE) язык Java, С++, С#, Python. С, Р, в PHP, Изобразительное Basic.NET, в JavaScript, Руби, Перл, объект Паскаль, Objective-С, Дартс, Свифт, Скала, Котлин, общий Лисп, Матлаб, и на языке Smalltalk.

Объектно-ориентированное программирование использует объекты. Но не все связанные с ними методы и структуры поддерживаются непосредственно в языках. Которые утверждают. Что поддерживают ООП.

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

Общий с не-ООП языками

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

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

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

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

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

  • Объекты – экземпляры классов

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

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

Junade Ali, Mastering PHP Design Patterns[8]

Каждый объект считается экземпляром определенного класса (например. Объект с полем имени. Установленным в Процедуры в объектно-ориентированном программировании известны как методы; переменные также известны как поля, члены. Атрибуты или свойства.

Это приводит к следующим условиям:

  • Переменные класса – принадлежат классу в целом; существует только одна копия каждой
  • Переменные экземпляра или атрибуты – данные. Принадлежащие отдельным объектам; каждый объект имеет свою собственную копию каждого
  • Переменные – члены-относится как к классу. Так и к переменным экземпляра. Которые определены определенным классом.
  • Методы класса – принадлежат классу в целом и имеют доступ только к переменным класса и входным данным вызова процедуры
  • Методы экземпляра – принадлежат отдельным объектами имеют доступ к переменным экземпляра для конкретного объекта . На который они вызываются. Входным данным и переменным класса

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

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

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

.

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

Класс на основе против прототипа на основе

В языках, основанных на классах, классы определяются заранее, а объекты создаются на основе этих классов. Если два объекта apple и orange созданы из класса Fruit, они по своей сути являются фруктами. И гарантируется. Что вы можете обрабатывать их одинаково; например. Программист может ожидать существования одних и тех же атрибутов. Таких как color, sugar_content или is_ripe.

В языках, основанных на прототипах, объекты являются первичными сущностями. Никаких классов даже не существует. Прототип объекта — это просто другой объект. С которым объект связан. Каждый объект имеет одну ссылку прототипа (и только одну). Новые объекты могут быть созданы на основе уже существующих объектов. Выбранных в качестве их прототипа. Вы можете назвать два разных объекта яблоко и апельсин плодом. Если объект плод существует. И оба яблока и апельсин имеют плод в качестве своего прототипа. Идея фруктового класса не существует явно. Но как класс эквивалентности объектов. Имеющих один и тот же прототип. Атрибуты и методы прототипа делегируются всем объектам класса эквивалентности. Определенного этим прототипом. Атрибуты и методы, принадлежащие по отдельности объекту. Могут не совместно использоваться другими объектами того же класса эквивалентности; например. Атрибут sugar_content может неожиданно отсутствовать в apple. Только одно наследование может быть реализовано через прототип.

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

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

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

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

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

Если класс не позволяет вызывающему коду обращаться к внутренним объектным данным и разрешает доступ только через методы. Это сильная форма абстракции или сокрытия информации. Известная как инкапсуляция. Некоторые языки (например. Java) позволяют классам явно применять ограничения доступа, например. Обозначая внутренние данные с privateпомощью ключевого слова и обозначая методы. Предназначенные для использования кодом вне класса с publicпомощью ключевого слова. Методы также могут быть разработаны на государственном. Частном или промежуточном уровнях. Таких как protected (который допускает доступ из одного и того же класса и его подклассов. Но не из объектов другого класса). В других языках (например. Python) это применяется только по соглашению (например, privateметоды могут иметь имена. Начинающиеся с подчеркивания). Инкапсуляция не позволяет внешнему коду быть связанным с внутренней работой объекта. Это облегчает рефакторинг кода, например. Позволяя автору класса изменять то. Как объекты этого класса представляют свои данные внутренне. Не изменяя никакого внешнего кода (до тех пор. Пока вызовы Это также побуждает программистов помещать весь код. Связанный с определенным набором данных. В один и тот же класс. Который организует его для легкого понимания другими программистами. Инкапсуляция — это метод. Который поощряет развязку.

Состав, наследование. И делегация

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

Языки, поддерживающие классы. Почти всегда поддерживают наследование. Это позволяет классам быть расположенными в иерархии. Которая представляет отношения Например. Класс Employee может наследовать от класса Person. Все данные и методы. Доступные родительскому классу. Также появляются в дочернем классе с теми же именами. Например. Класс Person может определять переменные Они также будут доступны в классе Employee. Который может добавить переменные Этот метод позволяет легко повторно использовать одни и те же процедуры и определения данных. А также интуитивно отражать реальные отношения. Вместо того чтобы использовать таблицы базы данных и программные подпрограммы. Разработчик использует объекты. С которыми пользователь может быть более знаком: объекты из своего домена приложения.[9]

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

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

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

Открытый/закрытый принцип

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

Полиморфизм

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

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

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

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

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

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

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

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

Алан Кей, [12]

Другим ранним примером MIT был Sketchpad, созданный Иваном Сазерлендом в 1960-61 годах; в глоссарии технического отчета 1963 года. Основанного на его диссертации о Sketchpad. Сазерленд определил понятия [13] Кроме того, версия MIT ALGOL, AED-0, установила прямую связь между структурами данных ([14][15]

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

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

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

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

В 1970-х годах Smalltalk повлиял на сообщество Lisp, включив в него объектно-ориентированные методы, которые были представлены разработчикам с помощью машины Lisp. Эксперименты с различными расширениями Lisp (такими как ЦИКЛЫ и ароматизаторы , вводящие множественное наследование и миксины) в конечном итоге привели к общей объектной системе Lisp, которая интегрирует функциональное программирование и объектно-ориентированное программирование и позволяет расширять через мета-объектный протокол В 1980-х годах было предпринято несколько попыток разработать процессорные архитектуры. Включающие аппаратную поддержку объектов в памяти. Но они не увенчались успехом. Примеры включают Intel iAPX 432 и Linn Smart Rekursiv.

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

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

В ETH ZürichНиклаус Вирт и его коллеги также исследовали такие темы . Как абстракция данных и модульное программирование (хотя это было широко распространено в 1960-х или ранее).

Объектно-ориентированные функции были добавлены во многие ранее существовавшие языки. Включая Ada, BASIC, Fortran, Pascalи COBOL. Добавление этих функций в языки. Изначально не предназначенные для них. Часто приводило к проблемам с совместимостью и ремонтопригодностью кода.

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

Языки ООП

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

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

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

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

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

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

  • Поля, определяющие значения данных. Которые формируют сообщения. Такие как их длина. Кодовая точка и значения данных.
  • Объекты и коллекции объектов. Подобные тому. Что можно найти в программе Smalltalk для сообщений и параметров.
  • Менеджеры, подобные объектам IBM i, например каталогу файлов и файлам. Состоящим из метаданных и записей. Менеджеры концептуально предоставляют ресурсы памяти и обработки для содержащихся в них объектов.
  • Клиент или сервер. Состоящий из всех менеджеров. Необходимых для реализации полной среды обработки. Поддерживающей такие аспекты. Как службы каталогов. Безопасность и контроль параллелизма.

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

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

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

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

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

Gang of Four design patterns

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

В книге описаны следующие закономерности:

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

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

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

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

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

Однако, Никлаус Вирт (который популяризировал лозунг сейчас известно как Вирт закон: «программное обеспечение все медленнее более стремительно. Чем оборудование будет быстрее») сказал. Что ООП в своей статье «хорошие идеи в Зазеркалье». «эта парадигма тесно отражает структуру системы ‘в реальном мире’. И поэтому хорошо подходит для моделирования сложных систем со сложным поведением»[28] (Для сравнения поцелуй принцип).

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

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

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

Ответственность — против дизайна

Дизайн, основанный на ответственности. Определяет классы в терминах контракта. То есть класс должен быть определен вокруг ответственности и информации. Которую он разделяет. Это противопоставляется Wirfs-Brock и Wilkerson с дизайном, управляемым данными. Где классы определяются вокруг структур данных. Которые должны храниться. Авторы считают, что дизайн. Ориентированный на ответственность. Предпочтительнее.

ТВЕРДЫЕ и ПОНЯТНЫЕ рекомендации

SOLID-это мнемоника. Изобретенная Майклом Перьями. Которая выступает за пять методов программирования:

GRASP (General Responsibility Assignment Software Patterns) — это еще один набор руководящих принципов. Пропагандируемых Крейгом Ларманом.

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

Лука Карделли утверждал. Что код ООП [36]. Последний пункт повторяется Джо Армстронгом, главным изобретателем Эрланга, который цитирует:]

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

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

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

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

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

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

Пол Грэм предположил. Что популярность ООП в крупных компаниях объясняется По словам Грэма. Дисциплина. Наложенная ООП. Не позволяет ни одному программисту [44]

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

Стив Йегге отметил. Что в отличие от функционального программирования:[47]

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

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

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

Роб Пайк, программист , участвовавший в создании UTF-8 и Go, назвал объектно-ориентированное программирование «римскими цифрами вычислений»[49] и сказал. Что языки ООП часто смещают фокус внимания со структур данных и алгоритмов на типы.]

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

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

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

Попытки найти консенсусное определение или теорию объектов оказались не очень успешными (однако формальные определения многих концепций и конструкций ООП см. в работе Abadi & Cardelli. A Theory of Objects[53]) и часто сильно расходятся. Например, некоторые определения фокусируются на умственной деятельности. А некоторые-на структурировании программ. Одно из более простых определений состоит в том. Что ООП-это акт использования синтаксическим и областным сахаром наверху. Наследование может быть выполнено путем клонирования карт (иногда называемого

См. также

Системы

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

  1. ^
  2. ^ Льюис, Джон; Лофтус, Уильям (2008). Java Software Solutions Основы проектирования программирования 6-е изд. Pearson Education Inc. ISBN 978-0-321-53205-3., раздел 1.6
  3. Дебора Дж.Армстронг. Кварки объектно-ориентированного развития. Обзор почти 40-летней компьютерной литературы. Который выявил ряд фундаментальных понятий. Найденных в подавляющем большинстве определений ООП. В порядке убывания популярности: Наследование. Объект, Класс. Инкапсуляция, Метод. Передача сообщений. Полиморфизм и Абстракция.
  4. ^ Джон С. Митчелл, Концепции в языках программирования, Cambridge University Press, 2003, ISBN 0-521-78098-5, p.278. Списки: Динамическая отправка, абстракция. Полиморфизм подтипа и наследование.
  5. ^ Майкл Ли Скотт, Прагматика языка программирования, Издание 2, Morgan Kaufmann, 2006, ISBN 0-12-633951-1, p. 470. Перечисляет инкапсуляцию. Наследование и динамическую отправку.
  6. ^ Пирс, Бенджамин (2002). Типы и языки программирования. MIT Press. ISBN 978-0-262-16209-8., раздел 18.1 Списки: Динамическая отправка. Инкапсуляция или мульти-методы (multiple dispatch). Полиморфизм подтипов. Наследование или делегирование. Открытая рекурсия (
  7. ^ Буч, Грейди (1986). Разработка программного обеспечения с помощью Ada. Addison Wesley. p. 220. ISBN 978-0-8053-0608-8. Возможно, самая большая сила объектно-ориентированного подхода к разработке заключается в том. Что он предлагает механизм. Который фиксирует модель реального мира.
  8. ^ Али, Джунаде (28 сентября 2016 года). Освоение шаблонов проектирования PHP | PACKT Books (1 изд.). Бирмингем, Англия. Великобритания: Packt Publishing Limited. p. 11. ISBN 978-1-78588-713-0. Проверено 11 декабря 2017года .
  9. ^ Якобсен, Ивар; Магнус Кристерсон; Патрик Йонссон; Гуннар Овергаард (1992). Объектно-Ориентированная Программная инженерия. Addison-Wesley ACM Press. ISBN 978-0-201-54435-0.
  10. ^ McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P.; Hods, L.; Luckham, D.; Maling, K.; Park, D.; Russell, S. (март 1960). (PDF). Бостон, Массачусетс: Группа искусственного интеллекта, Вычислительный центр M. I. T. и исследовательская лаборатория: 88f. Архивирован из оригинала (PDF) 17 июля 2010 года. В местном языке M. I. T. patois ассоциативные списки [атомарных символов] также называются
  11. ^ Маккарти, Джон; Абрахамс, Пол У.; Эдвардс, Дэниел Дж.; Харт, Свапнил Д.; Левин, Майкл И. (1962). LISP 1.5 Руководство программиста. MIT Press. p. 105. ISBN 978-0-262-13011-0. Объект — синоним атомарного символа
  12. ^ b , 2003 . Проверено 11 февраля 2010года .
  13. ^ Sutherland. I. E. (30 января 1963). . Технический отчет № 296, Лаборатория Линкольна. Массачусетский технологический институт через Центр технической информации обороны (stinet.dtic.mil). Извлечено 17 июля 2019года .
  14. ^ Развитие языков симулы, Кристен Нигаард, Оле-Йохан Даль, стр. 254 Uni-kl.ac.at
  15. ^ Росс, Дуг. . Временная шкала лаборатории LCS/AI. Лаборатория компьютерных наук и искусственного интеллекта Массачусетскоготехнологического института . Извлечено 13 мая 2010года .
  16. ^ b c Holmevik. Jan Rune (1994). (PDF). IEEE Annals of the History of Computing. 16 (4): 25–37. doi:10.1109/85.329756. Архивирован из оригинала (PDF) 30 августа 2017года . Проверено 3 марта 2018года .
  17. ^ Даль, Оле Йохан (2004). (PDF). От Объектной ориентации к Формальным методам. Конспект лекций по информатике. 2635. стр. 15-25. CiteSeerX 10.1.1.133.6730. doi:10.1007/978-3-540-39993-3_3. ISBN 978-3-540-21366-6. Проверено 3 марта 2018года .
  18. ^ b Бертран Мейер (2009). Прикосновение класса: Учимся хорошо программировать с объектами и Контрактами. Springer Science & Business Media. p. 329. Bibcode:2009tclp.book….. M. ISBN 978-3-540-92144-8.
  19. ^ — Кей, Алан. . Архивирован с оригинала 10 июля 2008года . Извлечено 13 сентября 2007года .
  20. ^ 1995 (июнь) Visual FoxPro 3.0, FoxPro эволюционирует от процедурного языка к объектно-ориентированному языку. Visual FoxPro 3.0 представляет контейнер базы данных. Бесшовные возможности клиент-сервер. Поддержку технологий ActiveX. А также OLE-автоматизацию и поддержку null. Краткое содержание выпусков Fox
  21. ^ Веб-сайт истории FoxPro: Foxprohistory.org
  22. ^ 1995 Руководство рецензентов по Visual FoxPro 3.0: DFpug.de
  23. ^ Хурана, Рохит (1 ноября 2009 года). Объектно-ориентированное программирование на C++, 1E. ISBN 978-81-259-2532-3.
  24. ^ . 26 февраля 2011 года.
  25. ^ Neward, Ted (26 июня 2006). . Взаимодействие Происходит. Архивирован с оригинала 4 июля 2006года . Получено 2 июня 2010года .
  26. ^ Мейер, Второе издание, с. 230
  27. ^ М. Трофимов, ООП – Третье Первый класс, ОМГ, 1993, Том 3, выпуск 3, с. 14.
  28. ^ Вирт, Никлаус (2006). (PDF). Компьютер. 39 (1): 28-39. doi:10.1109/mc.2006.20. Архивирован из оригинала (PDF) 12 октября 2016года . Извлечено 2 октября 2016года .
  29. ^ Йегге, Стив (30 марта 2006 года). . steve-yegge.blogspot.com. Извлечено 3 июля 2010года .
  30. ^ Борончик, Тимофей (11 июня 2009). . zaemis.blogspot.com. Извлечено 3 июля 2010года .
  31. ^ Эмблер, Скотт (1 января 1998). . drdobbs.com. Извлечено 4 июля 2010года .
  32. ^ Шелли, Асаф (22 августа 2008 года). . Программная сеть Intel. Извлечено 4 июля 2010года .
  33. ^ Джеймс, Джастин (1 октября 2007 года). . techrepublic.com. Архивирован с оригинала 10 октября 2007года . Извлечено 4 июля 2010года .
  34. ^ Шелли, Асаф (22 августа 2008 года). . support.microsoft.com. Извлечено 4 июля 2010года .
  35. ^ Роберт Харпер (17 апреля 2011). . Блог Экзистенциального Типа. Проверено 5 декабря 2011года .
  36. ^ b Cardelli. Luca (1996). . ACM Comput. Сурв. 28 (4es): 150–es. doi:10.1145/242224.242415. ISSN 0360-0300. Извлечено 21 апреля 2010года .
  37. Подпрыгните к: а б Армстронг, Джо. В книге Питер Сейбел, изд. Codersatwork.com Архивирован 5 марта 2010 года в Wayback Machine, доступен 13 ноября 2009 года.
  38. ^ b Степанов, Александр. . Проверено 21 апреля 2010года .
  39. ^ Jump up to: a b Rich Hickey. JVM Languages Summit 2009 keynote, Мы уже там? Ноябрь 2009 года.
  40. ^ Поток, Томас; Младен Воук; Энди Риндос (1999). (PDF). Программное обеспечение – Практика и опыт. 29 (10): 833–847. doi:. Извлечено 21 апреля 2010года .
  41. ^ C. J. Дата, Введение в системы баз данных, 6-е изд., Стр. 650
  42. ^ Си Джей Дейт. Хью Дарвен. Фонд будущих систем баз данных: Третий Манифест (2-е издание)
  43. ^ Крубнер, Лоуренс. . smashcompany.com… Архивировано с оригинала 14 октября 2014года . Проверено 14 октября 2014года .
  44. ^ Грэм, Пол. . PaulGraham.com. Извлечено 13 ноября 2009года .
  45. ^ Броуди, Лео (1984). Размышление вперед (PDF). Стр. 92-93. Извлечено 4 мая 2018года .
  46. ^ Охоться, Эндрю. . Категория Экстремальное программирование. Извлечено 4 мая 2018года .
  47. ^ . Извлечено 20 мая 2020года .
  48. ^ b Эрик С. Рэймонд (2003). . Извлечено 6 августа 2014года .
  49. ^ Пайк, Роб (2 марта 2004). . comp.os.plan9 (Список рассылки). Извлечено 17 ноября 2016года .
  50. ^ Пайк, Роб (25 июня 2012 года). . Проверено 1 октября 2016года .
  51. ^ Пайк, Роб (14 ноября 2012 года). . Архивирован с оригинала 14 августа 2018года . Проверено 1 октября 2016года .
  52. ^ Опрос, Эрик. (PDF). Проверено 5 июня 2011года .
  53. ^ b Абади, Мартин; Карделли, Лука (1996). Теория объектов. Springer-Verlag New York, Inc. ISBN 978-0-387-94775-4. Извлечено 21 апреля 2010года .

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

Внешние ссылки