Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
«Объектно-ориентированный» перенаправляет сюда. Для других значений объектно-ориентированного, см. Объектно-ориентированный .
«Объектно-ориентированный язык программирования» перенаправляется сюда. Список объектно-ориентированных языков программирования см. В разделе Список объектно-ориентированных языков программирования .

Парадигмы программирования
  • v
  • т
  • е

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

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

Многие из наиболее широко используемых языков программирования (например, C ++, Java, Python и т.д.), мульти-парадигмы , и они поддерживают объектно-ориентированное программирование в большей или меньшей степени, как правило , в сочетании с императива , процедурного программирования . Важные объектно-ориентированные языки включают: (порядок списков на основе индекса TIOBE ) Java , C ++ , C # , Python , R , PHP , Visual Basic.NET , JavaScript , Ruby , Perl , Object Pascal , Objective-C , Dart , Swift , Scala , Kotlin , Common Lisp , MATLAB и Smalltalk .

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

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

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

Совместно с языками, отличными от ООП [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объекты могут содержать другие объекты в своих переменных экземпляра; это известно как композиция объекта . Например, объект в классе 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 это finalключевое слово может использоваться для предотвращения создания подкласса.

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

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

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

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

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

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

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

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

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

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

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

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

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

Алан Кей, [12]

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

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

На ранних стадиях Simula должна была быть процедурным пакетом для языка программирования ALGOL 60. Недовольные ограничениями, наложенными ALGOL, исследователи решили превратить Simula в полноценный язык программирования, в котором использовался компилятор UNIVAC ALGOL 60. Simula продвигалась Далем и Найгаардом на протяжении 1965 и 1966 годов, что привело к увеличению использования языка программирования в Швеции, Германии и Советском Союзе . В 1968 году язык стал широко доступен на компьютерах Burroughs B5500 , а позже был реализован и на компьютере УРАЛ-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 по Алан Кей , Дэн Ingalls и Адель Голдберг . Smaltalk-72 включал среду программирования, был динамически типизирован и сначала интерпретировался , а не компилировался . Smalltalk стал известен своим применением объектной ориентации на уровне языка и графической средой разработки. Smalltalk прошел через различные версии, и интерес к языку рос. [18]Хотя на Smalltalk повлияли идеи, представленные в Simula 67, он был разработан как полностью динамическая система, в которой классы можно было создавать и изменять динамически. [19]

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

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

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

В начале и середине 1990-х объектно-ориентированное программирование стало доминирующей парадигмой программирования, когда языки программирования, поддерживающие эти методы, стали широко доступны. К ним относятся Visual FoxPro 3.0, [20] [21] [22] C ++ , [23] и Delphi [ необходима ссылка ] . Его доминирование было усилено растущей популярностью графических пользовательских интерфейсов , которые во многом основаны на методах объектно-ориентированного программирования. Пример тесно связанной библиотеки динамического графического интерфейса и языка ООП можно найти в фреймворках Какао в 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 . Каждая из этих двух структур по-своему демонстрирует преимущества использования ООП, создавая абстракцию от реализации. VB.NET и C # поддерживают межъязыковое наследование, позволяя классам, определенным на одном языке, создавать подклассы, определенные на другом языке.

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

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

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

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

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

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

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

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

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

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

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

Паттерны дизайна [ править ]

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

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

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

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

Паттерны проектирования «Банда четырех» [ править ]

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

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

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

  • Порождающие шаблоны (5): метод фабрика модель , абстрактный узор завода , Singleton шаблон , строитель шаблон , Prototype шаблон
  • Структурные модели (7): адаптер шаблон , шаблон Bridge , композитный шаблон , декоратор , Фасад шаблон , приспособленец , прокси - модель
  • Поведенческие модели (11): цепочка обязанностей , команда , интерпретатор шаблонов , итератор шаблон , Посредник шаблон , Memento шаблон , шаблон Observer , Паттерн состояние , стратегия шаблон , метод шаблона шаблон , шаблон для посетителей

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по SOLID и GRASP [ править ]

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 и языка программирования . [48]

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

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

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

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

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

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

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

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

  • Сравнение языков программирования (объектно-ориентированное программирование)
  • Сравнение парадигм программирования
  • Компонентная разработка программного обеспечения
  • Дизайн по контракту
  • Ассоциация объекта
  • База данных объектов
  • Язык объектного моделирования
  • Объектно-ориентированный анализ и дизайн
  • Несоответствие объектно-реляционного импеданса (и Третий манифест )
  • Объектно-реляционное отображение

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

  • КАДЕС
  • Общая архитектура брокера объектных запросов (CORBA)
  • Распределенная компонентная объектная модель
  • Распределенная архитектура управления данными
  • Джеру

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

  • IDEF4
  • Язык описания интерфейса
  • Лепус3
  • UML

Ссылки [ править ]

  1. ^ Киндлер, E .; Кривой, И. (2011). «Объектно-ориентированное моделирование систем со сложным управлением». Международный журнал общих систем: 313–343. Цитировать журнал требует |journal=( помощь )
  2. ^ Льюис, Джон; Лофтус, Уильям (2008). Программные решения Java Основы проектирования программирования 6-е изд . ISBN Pearson Education Inc. 978-0-321-53205-3., раздел 1.6 «Объектно-ориентированное программирование»
  3. ^ Дебора Дж. Армстронг. Кварки объектно-ориентированного развития . Обзор почти 40-летней компьютерной литературы, который выявил ряд фундаментальных концепций, встречающихся в подавляющем большинстве определений ООП, в порядке убывания популярности: наследование, объект, класс, инкапсуляция, метод, передача сообщений, полиморфизм и абстракция.
  4. ^ Джон С. Митчелл , Концепции языков программирования , Cambridge University Press, 2003, ISBN 0-521-78098-5 , стр.278. Списки: динамическая отправка, абстракция, полиморфизм подтипов и наследование. 
  5. ^ Майкл Ли Скотт, Прагматика языков программирования , издание 2, Морган Кауфманн, 2006, ISBN 0-12-633951-1 , стр. 470. Перечисляет инкапсуляцию, наследование и динамическую отправку. 
  6. ^ Пирс, Бенджамин (2002). Типы и языки программирования . MIT Press. ISBN 978-0-262-16209-8., раздел 18.1 «Что такое объектно-ориентированное программирование?» Списки: динамическая отправка, инкапсуляция или несколько методов (множественная отправка), полиморфизм подтипов, наследование или делегирование, открытая рекурсия («это» / «я»).
  7. ^ Буча, Грейди (1986). Разработка программного обеспечения с Ada . Эддисон Уэсли. п. 220. ISBN 978-0-8053-0608-8. Возможно, самая сильная сторона объектно-ориентированного подхода к разработке заключается в том, что он предлагает механизм, который отражает модель реального мира.Шаблон: Sonderholliday
  8. ↑ Али, Джунаде (28 сентября 2016 г.). Освоение шаблонов проектирования PHP | PACKT Книги (1-е изд.). Бирмингем, Англия, Великобритания: Packt Publishing Limited. п. 11. ISBN 978-1-78588-713-0. Проверено 11 декабря 2017 года .
  9. ^ Якобсен, Ивар; Магнус Кристерсон; Патрик Йонссон; Гуннар Овергаард (1992). Объектно-ориентированное программное обеспечение . Эддисон-Уэсли ACM Press. С.  43–69 . ISBN 978-0-201-54435-0.
  10. ^ Маккарти, J .; Брайтон, Р .; Эдвардс, Д .; Фокс, П .; Ходс, Л .; Лакхэм, Д .; Малинг, К .; Парк, Д .; Рассел, С. (март 1960). "Руководство программиста LISP I" (PDF) . Бостон , Массачусетс : Группа искусственного интеллекта, Вычислительный центр Массачусетского технологического института и исследовательская лаборатория : 88f. Архивировано из оригинального (PDF) 17 июля 2010 года. В местном наречии Массачусетского технологического института ассоциативные списки [атомарных символов] также называются «списками свойств», а атомарные символы иногда называются «объектами». Цитировать журнал требует |journal=( помощь )
  11. ^ Маккарти, Джон ; Abrahams, Paul W .; Эдвардс, Дэниел Дж .; Hart, swapnil d .; Левин, Михаил Иванович (1962). Руководство программиста LISP 1.5 . MIT Press . п. 105 . ISBN 978-0-262-13011-0. Объект - синоним атомного символа
  12. ^ a b «Доктор Алан Кей о значении« объектно-ориентированного программирования » » . 2003 . Проверено 11 февраля 2010 года .
  13. Перейти ↑ Sutherland, IE (30 января 1963 г.). «Скетчпад: графическая коммуникационная система человек-машина» . Технический отчет № 296, Лаборатория Линкольна, Массачусетский технологический институт, через Центр технической информации Министерства обороны (stinet.dtic.mil) . Проверено 17 июля 2019 .
  14. ^ Развитие Simula языков, Кристен Найгаард , Оле-Йохан Даль , стр.254 Uni-kl.ac.at
  15. ^ Росс, Дуг. «Первый язык программной инженерии» . Хронология лаборатории LCS / AI . Лаборатория компьютерных наук и искусственного интеллекта Массачусетского технологического института . Проверено 13 мая 2010 года .
  16. ^ a b c Холмевик, Ян Руне (1994). «Компиляция Simula: историческое исследование технологического генезиса» (PDF) . IEEE Annals of the History of Computing . 16 (4): 25–37. DOI : 10.1109 / 85.329756 . Архивировано из оригинального (PDF) 30 августа 2017 года . Проверено 3 марта 2018 .
  17. ^ Даль, Оле Йохан (2004). «Рождение объектной ориентации: языки Simula» (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. ^ a b Бертран Мейер (2009). Touch of Class: Учимся хорошо программировать с объектами и контрактами . Springer Science & Business Media. п. 329. Bibcode : 2009tclp.book ..... M . ISBN 978-3-540-92144-8.
  19. ^ Кей, Алан. «Ранняя история Smalltalk» . Архивировано из оригинала 10 июля 2008 года . Проверено 13 сентября 2007 года .
  20. ^ 1995 (июнь) Visual FoxPro 3.0, FoxPro эволюционирует от процедурного языка к объектно-ориентированному языку. Visual FoxPro 3.0 представляет контейнер базы данных, бесшовные возможности клиент / сервер, поддержку технологий ActiveX, а также автоматизацию OLE и поддержку null. Резюме релизов Fox
  21. ^ Веб-сайт истории FoxPro: Foxprohistory.org
  22. ^ Руководство обозревателя Visual FoxPro 3.0, 1995 : DFpug.de
  23. ^ Khurana, Рохит (1 ноября 2009). Объектно-ориентированное программирование на C ++, 1E . ISBN 978-81-259-2532-3.
  24. ^ "Изумрудный язык программирования" . 26 февраля 2011 г.
  25. ^ Ньюард, 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 . Проверено 2 октября +2016 .
  29. ^ Yegge, Стив (30 марта 2006). «Казнь в царстве существительных» . steve-yegge.blogspot.com . Проверено 3 июля 2010 года .
  30. ^ Boronczyk, Тимоти (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 г.). «КАК: Рекомендации по проектированию классов Visual C ++ для многоядерного программирования (многопроцессорность), функции-члены» . support.microsoft.com . Проверено 4 июля 2010 года .
  35. ↑ Роберт Харпер (17 апреля 2011 г.). «Некоторые мысли по обучению ФП» . Блог экзистенциального типа . Проверено 5 декабря 2011 года .
  36. ^ a b Карделли, Лука (1996). «Плохие инженерные свойства объектно-ориентированных языков» . ACM Comput. Surv . 28 (4es): 150 – es. DOI : 10.1145 / 242224.242415 . ISSN 0360-0300 . Проверено 21 апреля 2010 года . 
  37. ^ а б Армстронг, Джо. В « Кодеры за работой: размышления о ремесле программирования». Питер Сейбел, изд. Codersatwork.com Архивировано 5 марта 2010 г. на Wayback Machine , по состоянию на 13 ноября 2009 г.
  38. ^ а б Степанов Александр . "STLport: Интервью с А. Степановым" . Проверено 21 апреля 2010 года .
  39. ^ a b Рич Хики, доклад на саммите языков JVM, 2009 г., Уже приехали ли мы? Ноябрь 2009 г.
  40. ^ Поток, Томас; Младен Вук; Энди Риндос (1999). «Анализ производительности объектно-ориентированного программного обеспечения, разработанного в коммерческой среде» (PDF) . Программное обеспечение - практика и опыт . 29 (10): 833–847. DOI : 10.1002 / (SICI) 1097-024X (199908) 29:10 <833 :: AID-SPE258> 3.0.CO; 2-P . Проверено 21 апреля 2010 года .
  41. ^ CJ Date, Введение в системы баз данных, 6-е изд., Стр. 650
  42. ^ Дата CJ, Хью Дарвен. Основа для систем баз данных будущего: Третий манифест (2-е издание)
  43. ^ Крубнер, Лоуренс. «Объектно-ориентированное программирование - дорогостоящая катастрофа, которой необходимо положить конец» . smashcompany.com. Архивировано из оригинального 14 октября 2014 года . Проверено 14 октября 2014 года .
  44. ^ Грэм, Пол . «Почему ARC не является особенно объектно-ориентированным» . PaulGraham.com . Проверено 13 ноября 2009 года .
  45. Перейти ↑ Brodie, Leo (1984). Мыслить дальше (PDF) . С. 92–93 . Дата обращения 4 мая 2018 .
  46. ↑ Хант, Эндрю. «Не повторяйся» . Категория Экстремальное программирование . Дата обращения 4 мая 2018 .
  47. ^ "Блог Стива Рэнтс: Казнь в Королевстве существительных" . Проверено 20 мая 2020 .
  48. ^ a b Эрик С. Реймонд (2003). «Искусство программирования Unix: Unix и объектно-ориентированные языки» . Проверено 6 августа 2014 .
  49. ↑ Пайк, Роб (2 марта 2004 г.). "[9fans] Re: Threads: Пришивание почетных знаков к ядру" . comp.os.plan9 (Список рассылки) . Проверено 17 ноября +2016 .
  50. ↑ Пайк, Роб (25 июня 2012 г.). «Меньше значит экспоненциально больше» . Проверено 1 октября +2016 .
  51. ↑ Пайк, Роб (14 ноября 2012 г.). «Несколько лет назад я видел эту страницу» . Архивировано из оригинального 14 августа 2018 года . Проверено 1 октября +2016 .
  52. ↑ Опрос, Эрик. «Подтипы и наследование категориальных типов данных» (PDF) . Проверено 5 июня 2011 года .
  53. ^ а б Абади, Мартин ; Карделли, Лука (1996). Теория объектов . ISBN компании Springer-Verlag New York, Inc. 978-0-387-94775-4. Проверено 21 апреля 2010 года .

Дальнейшее чтение [ править ]

  • Абади, Мартин ; Лука Карделли (1998). Теория объектов . Springer Verlag . ISBN 978-0-387-94775-4.
  • Абельсон, Гарольд ; Джеральд Джей Сассман (1997). Структура и интерпретация компьютерных программ . MIT Press . ISBN 978-0-262-01153-2.
  • Армстронг, Дебора Дж. (Февраль 2006 г.). «Кварки объектно-ориентированного развития». Коммуникации ACM . 49 (2): 123–128. DOI : 10.1145 / 1113034.1113040 . ISSN  0001-0782 .
  • Буч, Грэди (1997). Объектно-ориентированный анализ и дизайн с приложениями . Эддисон-Уэсли . ISBN 978-0-8053-5340-2.
  • Илес, Питер; Оливер Симс (1998). Строительство бизнес-объектов . Джон Вили и сыновья . ISBN 978-0-471-19176-6.
  • Гамма, Эрих ; Ричард Хелм ; Ральф Джонсон ; Джон Влиссидес (1995). Шаблоны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования . Эддисон-Уэсли. Bibcode : 1995dper.book ..... G . ISBN 978-0-201-63361-0.
  • Хармон, Пол ; Уильям Моррисси (1996). Сборник примеров объектных технологий - уроки отмеченных наградами бизнес-приложений . Джон Вили и сыновья. ISBN 978-0-471-14717-6.
  • Якобсон, Ивар (1992). Объектно-ориентированная разработка программного обеспечения: подход на основе вариантов использования . Эддисон-Уэсли. Bibcode : 1992oose.book ..... J . ISBN 978-0-201-54435-0.
  • Кей, Алан . Ранняя история Smalltalk . Архивировано из оригинала 4 апреля 2005 года . Проверено 18 апреля 2005 года .
  • Мейер, Бертран (1997). Построение объектно-ориентированного программного обеспечения . Прентис Холл . ISBN 978-0-13-629155-8.
  • Печиновский, Рудольф (2013). ООП - Изучите объектно-ориентированное мышление и программирование . Bruckner Publishing. ISBN 978-80-904661-8-0.
  • Рамбо, Джеймс ; Майкл Блаха; Уильям Премерлани; Фредерик Эдди; Уильям Лоренсен (1991). Объектно-ориентированное моделирование и дизайн . Прентис Холл. ISBN 978-0-13-629841-0.
  • Шах, Стивен (2006). Объектно-ориентированная и классическая программная инженерия, седьмое издание . Макгроу-Хилл . ISBN 978-0-07-319126-3.
  • Шрайнер, Аксель-Тобиас (1993). Объектно-ориентированное программирование с ANSI-C . Hanser. ЛВП : 1850/8544 . ISBN 978-3-446-17426-9.
  • Тейлор, Дэвид А. (1992). Объектно-ориентированные информационные системы - планирование и внедрение . Джон Вили и сыновья. ISBN 978-0-471-54364-0.
  • Вайсфельд, Мэтт (2009). Объектно-ориентированный процесс мышления, третье издание . Эддисон-Уэсли . ISBN 978-0-672-33016-2.
  • Запад, Дэвид (2004). Объектное мышление (справочник разработчика) . Microsoft Press . ISBN 978-0-7356-1965-4.

Внешние ссылки [ править ]

  • Объектно-ориентированное программирование в Curlie
  • Введение в концепции объектно-ориентированного программирования (ООП) и многое другое от LWC Nirosh
  • Обсуждение недостатков ООД
  • Концепции ООП (Учебники по Java)
  • Наука или змеиное масло: эмпирическая разработка программного обеспечения Мысли о программном обеспечении и системной инженерии, Ян Соммервилл (2011-8-29)