в чем заключалась суть революции ооп если такая революция имело место

В чем заключалась суть революции ооп если такая революция имело место

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

А в чем же суть революции ООП?

От чего отказались и к чему пришли?

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

Рекомендую задать этот вопрос в форум по Smalltalk-у, наверняка получите большой спектр мнений.

Здесь интересно совсем другое. Почему SunWert поместил свой вопрос в рубрику «Интеллектуальные информационные технологии«? При чём здесь ООП и интеллект?

Источник

ГДЗ по истории 10 класс учебник Сороко-Цюпа параграф 22

Определите особенности политики «шоковой терапии» в разных странах. Какие страны и почему быстрее других преодолели сложности 1 990-х гг.?

Сравните Венгерское народное восстание 1956 г и Пражскую весну 1968 г. Выделите общие черты и различия.

Объясните, почему попытки реформ «реального социализма» окончились провалом.

Почему Польша стала первой страной, где произошла революция?

Какие реформы, по вашему мнению, были первоочередными на повестке дня после революций?

Объясните понятие «шоковая терапия», перечислите её основные признаки.

1. В каких странах социалистического лагеря пытались проводить реформы и чем они закончились?

2. Почему, по вашему мнению, «реальный социализм» оказался тупиковой ветвью развития?

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

3. Какую роль сыграла перестрой­ка в СССР в развитии событий в странах социалистического лагеря в 1980-е гг.?

«Перестройка» — общее название реформ и новой идеологии советского партийного руководства, используемое для обозначения больших и неоднозначных перемен в экономической и политической структуре СССР, инициированных генеральным секретарём ЦК КПСС М. С. Горбачёвым в 1985—1991 годах. Началом перестройки считают 1987 год, когда на январском пленуме ЦК КПСС перестройка была объявлена направлением развития государства.

4. Чем была вызвана одновременность революций 1989-1991 гг.?

— кризис тоталитарных режимов, прежде всего в СССР;

— неспособность административно-командных методов управления вывести страну из экономического и политического кризисов;

— падение жизненного уровня населения.

5. Почему ре­волюции 1989-1991 гг. были почти во всех странах «бархатными»? Объясните это название.

Термин «бархатная революция» был введен в оборот осенью 1989 года, для того чтобы подчеркнуть особый характер смены режима, достигнутой путем договоренностей и представлявшей собой настоящее действо с участием мирных масс, которая произошла в маленьком центральноевропейском государстве, ныне уже не существующем.

6. Почему политика после революций 1989-1991 гг. получила название «шоковая терапия»?

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

1. Выделите главное противоречие послереволюционной эпохи. В чём оно
проявилось, по вашему мнению?

2. Что, по вашему мнению, означает лозунг «Назад в Европу!»?

Латинская Америка

Материалы для самостоятельной работы и проектной деятельности

В чем отличие национал-реформистской политики от курса левых националистических режимов?

Почем стал востребованной политика неоконсервативного поворот в 1970- гг.?

Почему с конца XX в. Латинская Америка развивается без диктатур и революций?

1. Объясните национал-реформистский вариант политики на примере перонизма в Аргентине.

2. В чём особенность политики революционных левых националистических режимов в Латинской Америке в 1960-1970-е гг.?

3. Охарактеризуйте роль иностранного капитала в экономике стран Латинской Америки во второй половине XX в.

4. Среди множества причин выделите наиболее важные, по вашему мнению, обусловившие переход к демократизации в Латинской Америке в 1980-1990-е гг.

1) Вмешательство США
2) Распад СССР и стран варшавского договора

5. Какую политику проводили диктатуры в странах Латинской Америки?

1. Подумайте, представители каких политических сил назвали Кубу Островом
свободы? Какой смысл, по вашему мнению, в него вложили авторы метафоры? К какому этапу истории Кубы вы бы отнесли эту метафору и почему?

2. Что такое «аргентинский парадокс», как вы его понимаете?

3. Используя дополнительные источники, примеры из истории стран Латинской Америки, Азии, а также отечественной истории XX в., подготовьте аргументированный развёрнутый ответ на вопрос: почему демократия лучше, чем диктатура?

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

Источник

Забытая история ООП

Большинство парадигм программирования, которые мы используем сегодня, были впервые математически изучены в 1930-х годах с использованием идей лямбда-исчисления и машины Тьюринга, которые представляют собой варианты модели универсальных вычислений (это формализованные системы, которые могут выполнять вычисления общего назначения). Тезис Чёрча-Тьюринга показал, что лямбда-исчисление и машины Тьюринга функционально эквивалентны. А именно, речь идёт о том, что всё, что можно вычислить с использованием машины Тьюринга, можно вычислить и с использованием лямбда-исчисления, и наоборот.

Есть распространённое заблуждение, в соответствии с которым машины Тьюринга могут вычислить всё, поддающееся вычислению. Существуют классы проблем (например — проблема остановки), которые могут быть вычислимыми с использованием машин Тьюринга лишь для некоторых случаев. Когда в этом тексте используется слово «вычислимо», имеется в виду «вычислимо машиной Тьюринга».

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

Низкоуровневые языки программирования, вроде машинного кода или ассемблера, появились в 1940-е, а, к концу 1950-х, возникли первые популярные высокоуровневые языки, которые реализовали и функциональный и императивный подходы. Так, диалекты языка Lisp до сих пор широко используются, среди них можно отметить Clojure, Scheme, AutoLisp и так далее. В пятидесятых появились и такие языки, как FORTRAN и COBOL. Они являются примерами императивных высокоуровневых языков, которые всё ещё живы. Хотя надо отметить, что языки семейства C, в большинстве сфер, заменили и COBOL, и FORTRAN.

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

Первый известный мне объект был использован Айвеном Сазерлендом в его судьбоносном приложении Sketchpad, созданном между 1961 и 1962, описанном им в этой работе в 1963 году. Объекты представляли собой графические знаки, выводимые на экране осциллографа (возможно это — первый в истории случай использования графического компьютерного монитора), и поддерживающие наследование через динамических делегатов, которые Айвен Сазерленд назвал в своей работе «мастер-объектами» (masters). Любой объект мог стать мастер-объектом, дополнительные экземпляры объекта были названы «реализациями» (occurrences). Это сделало систему Sketchpad обладателем первых из известных языков программирования, который реализовал прототипное наследование.

Первым языком программирования, широко известным как «объектно-ориентированный», был язык Simula, спецификации которого были разработаны в 1965 году. Как и Sketchpad, Silmula предусматривал работу с объектами, но также включал в себя классы, наследование, основанное на классах, подклассы, и виртуальные методы.

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

Мнение отца ООП об ООП

«Я придумал термин «объектно-ориентированный», и могу сказать, что я не имел в виду С++». Алан Кэй, конференция OOPSLA, 1997.

Алан Кэй придумал термин «объектно-ориентированное программирование», имея в виду язык программирования Smalltalk (1972). Этот язык разработали Алан Кэй, Дэн Инглз и другие сотрудники научно-исследовательского центра Xerox PARC в рамках проекта по созданию устройства Dynabook. Язык Smalltalk был более объектно-ориентированным, чем Simula. В Smalltalk всё является объектом, включая классы, целые числа и блоки (замыкания). Первоначальная реализация языка, Smalltalk-72, не имела возможностей создания подклассов. Эта возможность появилась в Smalltalk-76.

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

У JavaScript и Smalltalk много общего. Я сказал бы, что JavaScript — это месть Smalltalk миру за неправильное понимает концепции ООП. Оба эти языка поддерживают следующие возможности:

В переписке по электронной почте 2003-года Алан Кэй уточнил то, что он имел в виду, когда называл Smalltalk «объектно-ориентированным языком».

«ООП для меня означает лишь обмен сообщениями, локальное сохранение, и защита, и скрытие состояния, и крайне позднее связывание». Алан Кэй

Другими словами, в соответствии с идеями Алана Кэя, самыми важными ингредиентами ООП являются следующие:

Сущность ООП

Комбинация передачи сообщений и инкапсуляции служит нескольким важным целям:

«Я понял, что метафора клетки или компьютера поможет избавиться от данных[. ]». Алан Кэй

Говоря «поможет избавиться от данных», Алан Кэй, конечно, знал о проблемах, вызванных разделяемым мутабельным состоянием, и о сильной связанности, причиной которой является общий доступ к данным. Сегодня эти темы у всех на слуху. Но в конце 1960-х программисты ARPANET были недовольны необходимостью выбирать представление модели данных для своих программ до начала разработки программ. Разработчики хотели уйти от этой практики, так как, заранее загоняя себя в рамки, определяемые представлением данных, сложнее изменить что-то в будущем.

Проблема заключалась в том, что разные способы представления данных требовали, для доступа к ним, разного кода и разного синтаксиса в используемых в некий момент времени языках программирования. Святым Граалем здесь был бы универсальный способ для доступа к данным и для управления ими. Если все данные выглядели бы для программы одинаково, это решило бы множество проблем разработчиков, касающихся развития и сопровождения программ.
Алан Кэй пытался «избавиться» от идеи, в соответствие с которой данные и программы были, в каком-то смысле, самостоятельными сущностями. Они не рассматриваются таковыми в List или в Smalltalk. Тут нет разделения между тем, что можно делать с данными (со значениями, переменными, структурами данных, и так далее) и программными конструкциями вроде функций. Функции — это «граждане первого класса», а программам разрешено меняться во время их выполнения. Другими словами, в Smalltalk к данным нет особого, привилегированного отношения.

Алан Кэй, кроме того, рассматривал объекты как алгебраические структуры, что давало определённые, математически доказуемые, гарантии их поведения.

«Моё математическое образование позволило мне понять, что каждый объект может иметь несколько алгебраических моделей, связанных с ним, что могут быть целые группы подобных моделей, и что они могут быть очень и очень полезными». Алан Кэй

Было доказано, что так оно и есть, и это сформировало базу для объектов, таких, как промисы и линзы, причём, и на то и на другое оказала влияние теория категорий.
Алгебраическая природа того, как Алан Кэй видел объекты, позволила бы объектам обеспечить формальную верификацию, детерминистическое поведение, улучшило бы тестируемость, так как алгебраические модели — это, в сущности, операции, которые подчиняются нескольким правилам в форме уравнений.

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

Эти идеи были на десятилетия забыты в большинство объектно-ориентированных языков семейства C, включая C++, Java, C# и так далее. Но эти идеи начинают поиски обратного пути, в свежие версии наиболее широко используемых объектно-ориентированных языков.

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

Как JavaScript и Smalltalk ранее, большинство современных объектно-ориентированных языков становится всё более и более «мультипарадигменными». Нет причины выбирать между функциональным программированием и ООП. Когда мы смотрим на историческую сущность каждого из этих подходов, они выглядят не только как совместимые, но и как дополняющие друг друга идеи.

Что, в соответствии с мыслями Алана Кэя, является самым главным в ООП?

Вот пара примеров на JavaScript:

Взаимоотношения универсальных типов может быть сложно правильно и полно выразить в языках вроде TypeScript, но это очень просто сделать в системе типов Хиндли-Милнера, применяемой в Haskell, поддерживающей типы высших родов (типы типов).

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

Если ваша система типов отличается слишком большим числом ограничений (как в TypeScript или в Java), то вы, для достижения тех же целей, вынуждены писать более сложный код, чем при использовании языков с более свободным подходом к типизации. Это не значит, что использование статических типов — это неудачная идея, или что все реализации статических типов характеризуются одинаковыми ограничениями. Я, например, сталкивался с гораздо меньшим количеством проблем, работая с системой типов Haskell.

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

Если ограничения упрощают ваш код — это замечательно! Но если ограничения принуждают вас к написанию более сложного кода, то, возможно, что-то не так с этими ограничениями.

Что такое «объект»?

Слово «объект», со временем, приобрело множество побочных оттенков значения. То, что мы называем «объектами» в JavaScript — это просто составные типы данных, без намёков на что-то из программирования, основанного на классах, или на идеи Алана Кэя о передаче сообщений.

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

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

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

ООП больше не является настоящим ООП

Так как понятие «объект» в современных языках программирования означает гораздо меньше, чем означало для Алана Кэя, я использую слово «компонент» вместо слова «объект» для описания правил настоящего ООП. Многими объектами владеет и управляет напрямую некий сторонний по отношению к ним код на JavaScript, но компоненты должны инкапсулировать собственное состояние и контролировать его.

Вот что такое настоящее ООП:

Манипулирование объектами в JavaScript или использование наследования, основанного на классах, не означает, что некто занимается ООП-программированием. А вот использование компонентов такими способами — означает. Но от устоявшихся представлений о терминах очень сложно отвязаться, поэтому, возможно, нам надо оставить термин «ООП» и назвать то, для чего используются вышеописанные «компоненты», «программированием, ориентированным на сообщения» (Message Oriented Programming, MOP)? Ниже мы будем пользоваться термином «MOP», говоря о программировании, ориентированном на сообщения.

По случайности, английское слово «mop» переводится как «швабра», а их, как известно, используют для наведения порядка.

На что похоже хорошее MOP?

В большинстве современных программ имеется некий пользовательский интерфейс (User Interface, UI), ответственный за взаимодействие с пользователем, некий код, занятый управлением состоянием приложения (данными пользователя), и код, работающий с системой или отвечающий за обмен данными с сетью.

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

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

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

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

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

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

Настало время, чтобы мир программного обеспечения освободился бы от неудачного эксперимента с наследованием, основанным на классах, и принял бы математические и научные принципы, которые стояли у истоков ООП.

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

Поэтому не расстраивайтесь, если термин «MOP» не выглядит словом из жаргона программистов. Просто приведите своё ООП в порядок с помощью рассмотренных выше принципов MOP.

Источник

В чем заключалась суть революции ооп если такая революция имело место

Шустрый

Профиль
Группа: Участник
Сообщений: 86
Регистрация: 2.1.2007
Где: г.Новосибирск

Репутация: нет
Всего: нет

Мне тут задали такой вопросик:
Как известно, программирование начало развиваться как программирование структурного(процедурного) типа. В далбнейшем стиль программирования изменился, оно стало ООП. Вопрос в следующем в чем заключалась суть революции ООП, если такая революция имела место.

Нельзя говорить слова типо объект, класс и т.д.

Требуется конкретное техническое решение.

Шустрый

Профиль
Группа: Участник
Сообщений: 83
Регистрация: 5.12.2007

Репутация: нет
Всего: 3

Шустрый

Профиль
Группа: Участник
Сообщений: 86
Регистрация: 2.1.2007
Где: г.Новосибирск

Репутация: нет
Всего: нет

Эксперт

Профиль
Группа: Завсегдатай
Сообщений: 1801
Регистрация: 25.4.2006

Репутация: нет
Всего: 40

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

Если по делу всегда слушай Вики

Шустрый

Профиль
Группа: Участник
Сообщений: 83
Регистрация: 5.12.2007

Репутация: нет
Всего: 3

То что я написал выше для того, чтобы дать тебе понять, что твой вопрос по меньшей мере некорректен

Эксперт

Профиль
Группа: Завсегдатай
Сообщений: 1801
Регистрация: 25.4.2006

Репутация: нет
Всего: 40

Шустрый

Профиль
Группа: Участник
Сообщений: 86
Регистрация: 2.1.2007
Где: г.Новосибирск

Репутация: нет
Всего: нет

Но все таки что изменилось технически?
При поступлении на работу в 1С дают список вопросов один из них этот.

Шустрый

Профиль
Группа: Участник
Сообщений: 83
Регистрация: 5.12.2007

Репутация: нет
Всего: 3

Guitar_Player, ты имел в виду во франча?
позови автора и спроси что он имел в виду
вопрос поставлен некорректно
Что значит технически?

Шустрый

Профиль
Группа: Участник
Сообщений: 94
Регистрация: 3.12.2007

Репутация: нет
Всего: 3

Шустрый

Профиль
Группа: Участник
Сообщений: 83
Регистрация: 5.12.2007

Репутация: нет
Всего: 3

onsql, да он про какую-то непонятную технологию пишет
то что с++ Страуструп придумал?
но так ООП и до него было

Добавлено через 1 минуту и 2 секунды
onsql,
там первые пять глав стоит прочитать)
за исключением нотации, хотя для общего понимания развития УМЛ и ее можно

Шустрый

Профиль
Группа: Участник
Сообщений: 94
Регистрация: 3.12.2007

Репутация: нет
Всего: 3

Добавлено через 4 минуты и 47 секунд
Привести конкретный технический пример про абстрактную фигуру и конкретные треугольник, круг, квадрат и мол как раньше мы как дураки делали switch по типу фигуры, но теперь то, в постреволюционные времена дружно делаем виртуальный метод draw у фигуры и используем полиморфизм.

Шустрый

Профиль
Группа: Участник
Сообщений: 86
Регистрация: 2.1.2007
Где: г.Новосибирск

Репутация: нет
Всего: нет

А может революция заключалось в объединении данных и кода?

Шустрый

Профиль
Группа: Участник
Сообщений: 83
Регистрация: 5.12.2007

Репутация: нет
Всего: 3

Guitar_Player, а тебе надо в такую контору устраиваться, где так проводят собеседования?
она не понимает о чем она спрашивает, а вопрос задан некорректно
попроси переформулировать вопрос

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

Шустрый

Профиль
Группа: Участник
Сообщений: 83
Регистрация: 5.12.2007

Репутация: нет
Всего: 3

Архимед

Профиль
Группа: Завсегдатай
Сообщений: 2531
Регистрация: 12.6.2004
Где: Moscow

Репутация: нет
Всего: 93

void OOP_doSmth(struct OOP *obj, int arg)
<
obj->member += arg;
>

struct OOP *obj = (struct OOP *)malloc(sizeof(*obj));
OOP_ctor(obj);
obj->doSmth(obj, 123);

struct OOP
<
struct OOP_vftbl *vftbl;
// data
int member;
>;

PS. Пишу в контексте C/C++, ибо тема перемещена именно из С++.

Шустрый

Профиль
Группа: Участник
Сообщений: 83
Регистрация: 5.12.2007

Репутация: нет
Всего: 3

Архимед

Профиль
Группа: Завсегдатай
Сообщений: 2531
Регистрация: 12.6.2004
Где: Moscow

Репутация: нет
Всего: 93

Цитата(izekia @ 25.1.2008, 15:20 )

то есть в техническом плане революции не было

Шустрый

Профиль
Группа: Участник
Сообщений: 83
Регистрация: 5.12.2007

Репутация: нет
Всего: 3

Бывалый

Профиль
Группа: Участник
Сообщений: 155
Регистрация: 7.7.2007
Где: г. Киев

Репутация: нет
Всего: 3

Цитата(Guitar_Player @ 25.1.2008, 12:36 )

Вопрос в следующем в чем заключалась суть революции ООП

Бывалый

Профиль
Группа: Участник
Сообщений: 193
Регистрация: 28.11.2006
Где: Санкт-Петербург

Репутация: нет
Всего: нет

Шустрый

Профиль
Группа: Участник
Сообщений: 83
Регистрация: 5.12.2007

Репутация: нет
Всего: 3

Профиль
Группа: Участник
Сообщений: 40
Регистрация: 5.7.2007

Репутация: нет
Всего: нет

Я так понимаю, это все кровью и потом выработалось.

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

Наплодили программисты кучу функций с названиями cube_draw, line_draw, circle_draw. замучились и поняли, что полиморфизм и наследование это здорово.

Вот приблизительно так.

Executables research

Профиль
Группа: Завсегдатай
Сообщений: 1019
Регистрация: 14.7.2007
Где: Железнодорожный, МО, Россия

Репутация: нет
Всего: 9

Вот и пришел человек к мысли, хорошо, пусть дядя Вася напишет Базу Данных(TDataBaseManager), а я напишу клиента(т.е. АРМ). Это естественное разделение труда, но человек не сразу к этому пришел. Но все таки, чисто технически, как было, так и осталось! Компиллеры, просто включили в себя инструкции class, virtual и некоторые другие. Но все осталось в том же виде, Ваш процессор вообще не поймет разницы меж ООП и структурным методом написания программы. Потому что для него все подано практически в одинаковом виде!

Не техническое поменялось, а поменялось мышление программистов!