Какие исторические условия привели к тому, что объектно-ориентированное программирование стало основной парадигмой программирования?


14

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

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


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

Я гарантирую вам, что даже для вопроса о внешних факторах, programmers.stackexchange - лучшее место. У него есть масса людей, которые активно работают в отрасли, и многие из них работают с тех пор, как индустрия начала свою деятельность. У вас будет гораздо больше шансов найти там человека, который ответит на ваш вопрос превосходно, чем здесь.
Выберите

2
Smalltalk не начал его. Симула создал основные понятия объектной ориентации. То, что сделал Smalltalk, было взять эти идеи и превратить их в совершенно другую модель и присвоить название. Но стоит отметить, что ни один язык, который следует модели ОО Smalltalk, никогда не был очень успешным для создания программ. (За исключением Objective-C, который является особым случаем: Apple пихает его в горло всем, но никто за пределами экосистемы Apple не использует его.) Все успешные языки OO: C ++, Delphi, Java, C #, и т.д., используйте модель Simula.
Мейсон Уилер

1
Лего игрушечные кирпичи могут вписаться в качестве внешнего влияния ...
Джейми Ф

1
@ Мейсон: не уверен, что разделяет модели Simula и Smalltalk. Где бы вы положили Руби? LUA? Python? Javascript?
Кевин Клайн

Ответы:


10

Короткий ответ

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


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

В течение еще целого десятилетия разработка программного обеспечения для корпоративных приложений, других коммерческих приложений росла, а разработка программного обеспечения в целом продолжалась в течение всего 1970-х годов. Языки, которые до сих пор сохранились до наших дней (до 1980 года), были C, Cobol, Fortran и другие подобные. Большинство из этих языков являются процедурными. Lisp также существовал с того дня - однако я не уверен, что это был выдающийся язык общего назначения для коммерческой разработки. Знаменитый термин « модель водопада» был также придуман в начале 1970-х годов.

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

Я предполагаю, что к концу 70-х люди были сожжены - поскольку процедурные языки не соответствовали этим обещаниям. И новая парадигма Объектно-ориентированная, которая существовала с того времени, сделала ее большой. Хотя люди могут с этим не согласиться, я думаю, что C ++, который помогает знакомству и проверенному опыту, а также C и ориентация Promise of Object (изначально с названием C with Classes) еще в 1983 году, был краеугольным камнем успеха объектно-ориентированного программирования.

Некоторая ссылка для большей перспективы - http://journal.thedacs.com/issue/43/88

Так почему ОО?

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

РЕДАКТИРОВАТЬ
Я бы также добавил, что языки программирования развивались одновременно параллельно с такими фундаментальными понятиями (ОО-парадигма, Аспект, Виртуальные машины). Каждая новая концепция и новое мышление возникали только тогда, когда ее осваивали новые новые языки программирования - сохраняйте только знакомство, но изменяйте основы ядро! В то же время - эта новая концепция и новые языки появились только из-за новых проблем бизнеса. 1980-е годы - ОО для крупномасштабного программного обеспечения, 1990-е годы - Java в эпоху Интернета, PHP / ASP и многие другие - для Интернета. Инновации в языках программирования также были обусловлены главным образом прерывистой потребностью рынка.

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


Какими были характерные особенности смены и куда идти? Конец 70-х годов. Что разработчики понимают, что пора идти? Устали от процедурных, да, но должны быть родственники альтернатив?
Независимый

@Jonas - хорошо, - исправил ответ.
Дипан Мехта

Что касается исторического успеха, который мы оцениваем, мы можем определенно сказать, что знакомство играет определенную роль. C (был преемником B), C ++ был лучшим C, хотя OO якобы был изменением парадигмы. Даже Java был готовым переходом от C ++ (который больше походил на C ++ без проблем C ++. Например, память и переносимость). Большинство из этих языков преодолевали пропасти , более эффективно осваивая существующее пространство, хотя в них было что-то более фундаментальное. Более того, потому что каждый язык приобретет несколько программистов, которые уже знают некоторые другие языки программирования. НО это не всегда так!
Дипан Мехта

1
Я также хотел бы добавить, что языки программирования развивались одновременно параллельно с такими фундаментальными понятиями (ОО-парадигма, аспект, виртуальные машины). Каждая новая концепция и новое мышление возникали только тогда, когда ее осваивали новые новые языки программирования - сохраняйте только знакомство, но изменяйте основы из ядра ! В то же время - эта новая концепция и новые языки появились только из-за новых проблем бизнеса. 1980-е годы - ОО для крупномасштабного программного обеспечения, 1990 - Java в эпоху Интернета, PHP / ASP и многое другое для веб-сайтов. Инновации в языках программирования также были обусловлены главным образом прерывистой потребностью рынка.
Дипан Мехта

1
«Моделирование реального мира» звучит убедительно, но в большинстве случаев этого не происходит. У Customerкласса нет таких методов, как eatLunch, goToWorkили sleep, хотя это то, что клиенты делают в реальном мире . В Productклассе есть несколько методов, хотя большинство продуктов в реальном мире совершенно не работают . Поэтому я бы сказал, что модель ОО соответствует (более или менее) с точки зрения свойств, но никак не с точки зрения поведения, реальному миру. Но вам не нужна ОО, чтобы иметь модель данных, которая соответствует объектам реального мира. Типы записей - это все, что нужно.
user281377

6

Я думаю, что главной причиной был успех графических пользовательских интерфейсов, таких как X и Windows. Графический интерфейс пользователя состоит из нескольких объектов, которые имеют собственное поведение, что ОО может представить близко.

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


4

Я вижу ООП как естественный эволюционный шаг из процедурного кода:

  1. Процедурный код: Скажите машине сделать A, затем скажите ей сделать B.
  2. ООП: Упакуйте процедурные инструкции в очень многократно используемые фрагменты, определив интерфейсы / ввод / вывод. (Предупреждение: упрощение.)

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

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


2

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

Затем кто-то придумал структуры для программирования. На какое-то время делай то, что мы знаем сегодня. Это было большим нововведением, поскольку теперь приложения с относительно сложным потоком можно было легко писать и понимать. Так родилось структурированное программирование.

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.