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

Материал из wikixw
Перейти к навигации Перейти к поиску
"Объектно-ориентированный" перенаправляет сюда. Для других значений object-oriented см. раздел Object-orientation .

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

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

Многие из наиболее широко используемых языков программирования(например, C++, Object Pascal, Java, Python и т.д.) являются многопарадигмальными и в большей или меньшей степени поддерживают объектно-ориентированное программирование, как правило , в сочетании с императивным, процедурным программированием . Существенные объектно-ориентированные языки включают Java, C++, C#, Python, PHP, JavaScript, Рубин, Perl, Объект Pascal, Цель-C, Дротик, Swift, Scala, Общий Lisp, MATLAB, и Smalltalk.

Особенности[править]

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

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

Общий доступ к языкам, не являющимся предшественниками OOP[править]

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

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

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

Объекты и классы[править]

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

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

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

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

Junade Ali, освоение шаблонов дизайна PHP

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

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

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

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

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

Class-based vs prototype-based[править]

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

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

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

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

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

Инкапсуляция[править]

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

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

Состав, наследование и делегирование[править]

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

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

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

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

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

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

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

Полиморфизм[править]

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

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

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

Открыть рекурсию[править]

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

История[править]

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

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

Alan Kay,

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

В 1960-х годах объектно-ориентированное программирование было введено в практику с помощью языка Simula, который ввел важные понятия, которые сегодня являются существенной частью объектно-ориентированного программирования, такие как класс и объект , наследование и динамическая привязка .[16] Simula также была разработана с учетом программирования и безопасности данных . В целях обеспечения безопасности программирования процесс обнаружения был реализован таким образом, что с помощью счетчиков ссылок сборщик мусора в крайнем случае удалял неиспользуемые объекты в оперативной памяти (ОПЕРАТИВНАЯ ПАМЯТЬ.) Однако, несмотря на то , что идея объектов данных уже была создана к 1965 году, инкапсуляция данных через уровни области действия для переменных, таких как private (-) и public ( + ), не была реализована в Simula, потому что это потребовало бы, чтобы процедуры доступа также были скрыты.[17]

В 1962 году Кристен Найгард инициировала проект по языку моделирования в норвежском вычислительном центре, основанный на его предыдущем использовании моделирования Монте-Карло и его работе по концептуализации реальных систем. Оле-Йохан Даль официально присоединился к проекту, и язык программирования Simula был разработан для работы на универсальном автоматическом компьютере (UNIVAC) 1107. На ранних этапах Simula должна была стать пакетом процедур для языка программирования ALGOL 60. Недовольные ограничениями, наложенными ALGOL, исследователи решили разработать Simula в полноценный язык программирования, который использовал компилятор UNIVAC ALGOL 60. Simula была запущена в 1964 году, и продвигалась Dahl и Nygaard на протяжении 1965 и 1966 годов, что привело к более широкому использованию языка программирования в Швеции, Германии и Советском Союзе . В 1968 году язык стал широко доступен через компьютеры Burroughs B5500, а затем был также реализован на компьютере URAL-16 . В 1966 году Даль и Нюгард написали компилятор Simula. Они были озабочены внедрением в практику концепции класса записей Тони Хоара, которая была реализована в свободной форме, похожей на английский язык общего назначения SIMSCRIPT. Они ограничились обобщенной концепцией процесса со свойствами класса записи и вторым слоем префиксов. С помощью префикса процесс может ссылаться на предшественника и иметь дополнительные свойства. Simula таким образом представила иерархию классов и подклассов, а также возможность генерации объектов из этих классов. Компилятор Simula 1 и новая версия языка программирования Simula 67 были представлены всему миру в рамках исследовательской работы" объявления классов и подклассов " на конференции 1967 года.[18]

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

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

В 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++ .[20] In 1985, Bertrand Meyer также производится первый дизайн языка Эйфеля . Ориентированная на качество программного обеспечения, Eiffel является чисто объектно-ориентированным языком программирования и нотацией, поддерживающей весь жизненный цикл программного обеспечения. Мейер описал метод разработки программного обеспечения Eiffel, основанный на небольшом числе ключевых идей из программной инженерии и информатики, в объектно-ориентированном программном обеспечении . Существенным для качественного фокуса Eiffel является механизм надежности Мейера, дизайн по контракту, который является неотъемлемой частью как метода, так и языка.

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

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

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

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

Языки OOP[править]

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

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

  • Языки, называемые "чистыми" OO языками, потому что все в них рассматривается последовательно как объект, от примитивов, таких как символы и знаки препинания, до целых классов, прототипов, блоков, модулей и т.д. Они были разработаны специально для облегчения и даже обеспечения применения методов ОО. Примеры: Python, Ruby, Scala , Smalltalk , Eiffel, Emerald, [26] JADE, Self .
  • Языки конструированные главным образом для программирования ОО, но с некоторыми процедурными элементами. Примеры: Java, C++, C#, Delphi / Object Pascal , VB.NET .
  • Языки, которые исторически являются процедурными языками, но были расширены некоторыми функциями OO. Примеры: PHP, Perl, Visual Basic (производный от BASIC), MATLAB , COBOL 2002 , Fortran 2003 , ABAP , Ada 95 , Pascal .
  • Языки с большинством признаков объектов (классы, методы, наследование), но в отчетливо оригинальной форме. Примеры: Oberon (Оберон-1 или Оберон-2).
  • Языки с поддержкой абстрактных типов данных, которые могут быть использованы, чтобы походить на OO программирование, но без всех особенностей объектной ориентации. Это включает объектные и прототипные языки. Примеры: JavaScript, Lua, Modula-2, CLU .
  • Языки хамелеонов, которые поддерживают несколько парадигм, включая OO. Tcl выделяется среди них для TclOO, гибридной объектной системы, которая поддерживает как основанное на прототипе Программирование, так и основанное на классе OO.

OOP в динамических языках[править]

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

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

OOP в сетевом протоколе[править]

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

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

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

Шаблоны дизайна[править]

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

Наследование и поведенческий подтип[править]

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

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

Группа из четырех шаблонов дизайна[править]

Основная статья: Design pattern (информатика)

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

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

  • Creational картины (5): картина метода фабрики, абстрактная картина фабрики , картина Синглтона , картина строителя , картина прототипа
  • Структурные картины (7): картина переходника, картина моста , составная картина, картина декоратора, картина фасада , картина Flyweight , картина Proxy
  • Поведенческие паттерны (11): паттерн цепи ответственности, паттерн команды, паттерн интерпретатора, паттерн итератора, паттерн посредника , паттерн памятки, паттерн наблюдателя, паттерн состояния, паттерн стратегии, паттерн метода шаблона, паттерн посетителя.

Объектная ориентация и базы[править]

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


И объектно-ориентированное программирование, и системы управления реляционными базами данных (RDBMSs)ООП чрезвычайно распространены в программном обеспечении сегодня . Поскольку реляционные базы данных не хранят объекты напрямую (хотя некоторые RDBMS ООП имеют объектно-ориентированные функции для приближения к этому), существует общая потребность в объединении двух миров. Проблема соединения объектно-ориентированных программ доступа и шаблонов данных с реляционными базами данных известна как несоответствие объектно-реляционного импеданса . Существует ряд подходов к решению этой проблемы, но нет общего решения без недостатков. Одним из наиболее распространенных подходов является объектно-реляционное сопоставление , как найдено в языках IDE, таких как Visual FoxPro и библиотеках, таких как объекты данных Java и Ruby on Rails ' ActiveRecord.

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

Реальное моделирование и отношения[править]

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

Однако, Никлаус Вирт (который популяризировал лозунг сейчас известно как Вирт закон: "программное обеспечение замедляется более быстро, чем аппаратура становится быстрее") сказал, что ООП в своей статье "хорошие идеи в Зазеркалье", "эта парадигма точно отражает структуры систем 'в реальном мире', и поэтому хорошо подходит для моделирования сложных систем со сложным поведением"[30] (контраст Kiss принцип).

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

OOP и поток управления[править]

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

Ответственность-против проектирования на основе данных[править]

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

=Твердые и понять руководящие принципы[править]

SOLID-это мнемоника, придуманная Майклом перышком, которая стоит за и защищает пять методов программирования:

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

Критика[править]

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

Лука Карделли утверждал, что код OOP "внутренне менее эффективен", чем процессуальный код, что компиляция OOP может занять больше времени, и что языки OOP имеют "чрезвычайно плохие свойства модульности в отношении расширения и модификации классов" и, как правило, чрезвычайно сложны.[38] последнее утверждение повторяется Джо Армстронгом, главным изобретателем Эрланга, который, как цитируется, сказал:]

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

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

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

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

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

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

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

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

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

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

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

Реймонд, программист Unix и сторонник открытого программного обеспечения, критиковал утверждения о том, что объектно-ориентированное программирование является "единственным истинным решением", и написал, что объектно-ориентированные языки программирования, как правило, поощряют многослойные программы, которые разрушают прозрачность.[50] Raymond сравнивает это неблагоприятно с подходом, принятым с Unix и языком программирования C .

Роб Пайк , программист, участвовавший в создании UTF-8 и Go , назвал объектно-ориентированное программирование "римскими цифрами вычислений" [51] и сказал, что языки OOP часто смещают акцент с структур данных и алгоритмов на типы .Кроме того, он приводит пример профессора Java, чьим "идиоматическим" решением проблемы было создание шести новых классов, а не просто использование таблицы поиска .

Формальная семантика[править]

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

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

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

  • алгебраические типы данных co [54]
  • абстрактные типы данных (которые имеют экзистенциальные типы ) позволяют определять модули, но они не поддерживают динамическую отправку
  • рекурсивные типы
  • инкапсулированное состояние
  • наследование
   записи являются основой для понимания объектов, если функциональные литералы могут храниться в полях (например, в языках функционального программирования), но фактические вычисления должны быть значительно более сложными, чтобы включать существенные особенности ООП. Были изучены несколько расширений системы F<:, которые имеют дело с изменяемыми объектами; [55] они позволяют как полиморфизм подтипа, так и параметрический полиморфизм (дженерики)

Попытки найти консенсусное определение или теорию объектов оказались не очень успешными (однако, см. Abadi & Cardelli, A Theory of Objects [55] for formal definitions of many OOP concepts and constructs), и часто расходятся широко. Например, некоторые определения фокусируются на умственной деятельности, а некоторые-на структурировании программ. Одно из более простых определений заключается в том, что ООП-это акт использования структур данных или массивов" карт", которые могут содержать функции и указатели на другие карты, все с некоторым синтаксическим и областью действия sugar сверху. Наследование может быть выполнено путем клонирования карт (иногда называемое "прототипирование").

См. также[править]

Системы[править]

Языки моделирования[править]

Читать[править]

/oomodels.org/


Пруф[править]

curlie.org/Computers/Programming/Methodologies/Object-Oriented