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

Цитата

ООП - это не просто набор некоторых свойств, добавленных в уже существующие языки. Это новый шаг в осмыслении задач и разработки ПО. Программы - это совокупность взаимодействующих объектов. Каждый объект отвечает за конкретную задачу. Вычисление осуществляется посредством взаимодействия объектов. Объект получается в результате инкапсуляции состояния (данных) и поведения (операций), во многом аналогично абстрактному типу данных - АТД. Поведение объекта диктуется классом. Данные и поведение представлены в виде классов, экземпляры которых - объекты. Все экземпляры одного класса будут вести себя одинаковым образом в ответ на одинаковые запросы. Объект проявляет свое поведение путем вызова метода в ответ на сообщение. Интерпретация сообщения зависит от объекта и может быть различной для различных классов объектов. Для удобства создания нового типа из уже существующих типов, определенных пользователем используется механизм наследования. Классы могут быть организованы в виде иерархического дерева наследования. С помощью уменьшения взаимозависимости ООП позволяет разрабатывать системы, пригодные для многократного использования. ООП - это взгляд на программирование, сосредоточенный на данных; в котором данные и поведение жестко связаны. Для этого необходимо, чтобы объекты определялись вместе с сообщениями, на которые они могут реагировать. Объектно-ориентированная парадигма предлагает новый подход к разработке программного обеспечения. Фундаментальная концепция объектно-ориентированной парадигмы состоит в передаче сообщений объектам. ООП является лишь последним звеном в длиной цепи решений, которые были предложены для разрешения "кризиса программного обеспечения". Кризис программного обеспечения означает, что те задачи, которые мы хотим решить, опережают наши возможности.

Я обращяюсь, к вам, как профессиональным программистам. И хочу, чтоб мне написали именно суть революции ООП. Суть - это точная, красиваю фраза из нескольких слов, которая так точно отражает мысль, что сам Архимед выпрыгнул бы из ванны!
Способны ли вы на такое, чем делать цитаты, ссылки на Страуструпа и флудить?
Добавлено @ 05:03
причем, желательно избегать таких слов как объекты, классы, инкапсуляция, параллелелизмполиморфизм и т.д. Способен ли кто из вас выразить суть в простых словах? Так чтоб человек, который не имеет отношения к программингу мог вас понять?

Я конечно не профессионал, но ИМХО ООП превнес в программирование приближение объектов реального мира к программным объектам, что значительно упросило работу с данными.

в ООП данные стали активными.

Сначала были просто объекты со свойствами, как в паскале record, потом добавились методы и т.д.

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

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

Подробнее читайте действительно у того же СтраусТрупа

Цитата(atamur @ 24.5.2004, 09:17)

Подробнее читайте действительно у того же СтраусТрупа

Лучше у Гради Буча, у него ООП рассматривается более абтрактно без привязки к определенному языку. К тому же книга написана очень доходчиво и интересно, с большим колличеством примеров.

Никакой революции не было. ООП - это просто набор выработанных практикой принципов программирования, позволяющих писать более надежный, переносимый и легкий в сопровождении код... Эти принципы оформили формально и сделали механизмы их поддержки со стороны языка. Причём пользоваться некоторыми из них можно было (и пользовались) без этой поддержки. Например, я использовал в сишных либах "hand-made VFT" в виде явно описанного массива указателей на функции для организации интерфейса с модулями-драйверами. Хорошо организованная сишная либа очень легко переводилась в C++, потому что уже была написана в объектном стиле.

В основном разница это подход к проблеме.
В процедуральном, мы описываем проссец работы. К примеру, откроем файл, запишем, закроем.
В ООП, мы описываем объект. К примеру, объект Файл, можно открыть, записать и закрыть.
Часто, объекты это реальные объекты иа жизни.

Что из этого следует?
Мне как программисту легче понять клиента, который описывает проблему как работу с объектами. Мне надо только внимательно реализовать реальные объекты в объекты в программе и дать им заимодействовать с друг другом.

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

Тема такая, что этот вопрос ОЧЕНЬ часто задают на собеседовании в крупных компаниях, при этом слово ОБЪЕКТ в ответе употреблять нельзя.
Говорят: Вот кодили процедурно, а потом начали ООП - с чем связан этот переход ?

Читайте Гради Буча "Объектно-ориентированный анализ и проектирование"

Цитата(GFX @ 8.8.2005, 08:24)

Вот кодили процедурно, а потом начали ООП - с чем связан этот переход ?

Цитата(Rentsch)

"В 1980-х годах объектно-ориентированное программирование будет занимать такое же место, какое занимало структурное программирование в 1970-х. но всем будет нравиться. Каждая фирма будет рекламировать свой продукт как зданный по этой технологии. Все программисты будут писать в этом стиле, причем все по-разному. Все менеджеры будут рассуждать о нем. И никто не будет знать, что же это такое"

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

Цитата(Михаил Клишевич @ 23.5.2004, 19:37 )

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

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

Понятие объектно-ориентированный подход, включает в себя три других, более мелких сущностей:
1. Объектно-ориентированный(ОО) анализ;
2. ОО проектирование
3. ОО программирование.

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

Если отвечать на Ваш вопрос, то собственно, сам факт разработки такого подхода, и его дальнейшее и повсеместное применение, дало многим людям основание сказать, что произошла ОО революция в программировании.

Где-то читал, что структурную программу становилось невозможно поддерживать, если её динна превышала 5 000 строк, процедурную - если превышала 50 000 и лишь ООП дало реальную возможность масштабировать бизнес-логику практически до беспредельных зазмеров.

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

Предел для ООП есть. Помоему, это 10 в 5-ой или 6-ой.
Дальше идет компонентно-ориентированное программирование (КОП), например, как в шарпах. Говорю по Шилдту.
Оно позволяет строить относительно независимые компоненты. Организация идет на высоком уровне и свосем не важно, что внутри каждого компонента. Не надо спрашивать: "А что, с классами не так?" Немного не так -- взять диаграмму хоть из 30 классов и долго будете понимать, что есть что. При КОП можно доходить до 10 в 8-ой. Дальше опять голова не держит.

Цитата(Cr@$h @ 6.1.2006, 04:15 )

например, как в шарпах

Ничего не понял. Причем тут С#?

Цитата(Cr@$h @ 6.1.2006, 04:15 )

Немного не так -- взять диаграмму хоть из 30 классов и долго будете понимать, что есть что.

А что позволяет КОП?

Цитата(Exception @ 6.1.2006, 21:29 )

Ничего не понял. Причем тут С#?

.NET в полной мере реализует КОП.

Цитата(Exception @ 6.1.2006, 21:29 )

А что позволяет КОП?

http://en.wikipedia.org/wiki/Component-oriented_programming

Цитата

A simpler definition can be: A component is an object written to a specification. It does not matter what the specification is: COM, Java Beans, etc., as long as the object adheres to the specification. It is only by adhering to the specification that the object becomes a component and gains features like reusability and so forth.

Дык ведь Ява это тоже поддерживает?

Exception
Ну никто же не говорил, что только .NET поддерживает КОП

Yak. Прочитал всю тему и понял, что невольно присоединился к флудерам. По-моему, у этой темы всего один вопрос .

Если по-программистски, то ООП сделало популярным ее три столпа:

• инкапсуляция;
• полиморфизм;
• наследование,

из которых главным я считаю последнее.

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

Всё-таки я не очень понимаю, в чём отличие КОП от ООП, может кто-нибудь более четко объяснить? Реализован ли он в Java?
Пока впечатление, что КОП - это лишь какие-то правила ООП-программирования, нацеленные на автоматизацию работы с объектами как с чёрным ящиком, декларируя определённые правила оформления интерфейса, типа концепции JavaBeans. Если так, то я не назвал бы это чем-то качественно-новым.

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

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

Steve Lohr в своей книге "Go to" в 2001 году писал примерно следующее:

Цитата

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

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

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

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

P.S. Мысли не мои, а Николаса Дж. Карра, хорошо изложенные в маленькой книжке "Блеск и нищета информационных технологий".

Именно так, Се ля ви, я с тобой согласен по поводу SOA. SOA, проталкиваемая MS, по-моему, просто противоречи принципам ООП, что можно в данном случае рассматривать как откат назад.

Лично я считаю, что никакой революции ООП Пока не было и лет 5-8 ещё не будет.

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

ООП сегодня - скорее выражение желания программистов почаще повторно использовать свой или чужой код или как-то разделить работу над крупным проектом на более менее конечные части. Причём пока методики ООП применяются либо в хорошо проторенных алгоритмах либо не очень важных частях проетов (либо чтобы побыстрее первую порцию денег с заказчика снять да ещё и за модность накруточку сделать).
Там где дело касается чего-то технически инновационного всё как и 20 лет назад скатывается к "переписыванию данного модуля на asm/C(всех видов и цветов), что даст нашей программе прирост по скорости в 20%".

Революция ООП на мой взгляд может случиться, когда идеи сегодняшнего ООП или скорее всего чего-то другого, построенного на принципах:
1) простое повторное использование кода
2) выделение стандартных, но сложных алгоритмов в полуаппаратные модули (к примеру интерфейс с пользователем вплоть до "окошечек, кнопочек", всякие сортировки, программируемые типы данных с проверкой целостности, и т. д.)
3) удобная нелинейная система адресации памяти (быть может отвечающая теоретическим принципам ООП)
4) единый аппаратно поддерживаемый стандарт на общие расшариваемые куски кода с аппаратной же проверкой зависимостей, а быть может и автоматическая подгрузка нужных модулей ну предположим из репозитория в интернете. Что-то типа постоянного обновления firmware для упрощения совместной разработки крупных поректов.

будут реализованы в процессорах, модулях памяти или том, что придёт им на смену.

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

P.S. Повторюсь. Это лично моё мнение.

Это сообщение отредактировал(а) ksicom - 27.1.2006, 01:58

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

имхо Вы необъективны в своих оценках и выводах.

Это не совсем верное суждение Се ля ви. Просто видимо, ты недостаточно знаком с теми архитектурными решениями, которые предлагает MS. Но тебе как джависту это простительно. Не нужно путать SOA и ООП. Это разные вещи.
Understanding Distributed Technologies - http://msdn.microsoft.com/webservices/unde...ng/default.aspx
Application Integration & Web Services - http://msdn.microsoft.com/practices/apptyp...eg/default.aspx

Не вижу в изначальном вопросе ничего ни про анализ, ни про проектирование. Старался свой топик строить в полном соответсвии с изначальным вопросом.

Если Вы ничего не видите про анализ и проектирование, то это еще не значит, что этого там нет.

OOP часто путают с OOA&D, что есть разные вещи. И, если так можно выразиться, "революцию" совершили идеи именно OOA&D. А OOP - это их практическое воплощение в виде кода.

Согласен.

Товарищи, объясните мне вот какой момент.

Я начинал программировать еще в школе, на ZX-Spectrum`е был вшит Бейсик и я на нем, что-то делал. Позднее, когда я открыл для себя Pascal я на деле убедился насколько это удобнее и проще использовать функции. Когда можно отладить законченную процедуру (функцию) и использовать ее забыв о тонкостях ее реализации. Вот это была для меня маленькая революция. Тем более, что язык позволяет внутри процедуры описывать другие процедуры. Таким образом, вся задача разбивалась на ряд локальных задач, каждую из которых можно было очень четко описать. И это было круто!!! (на сколько все-таки программирование продвинулось со времен ZX-Spectrumа, если вы знаете, что это такое)

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

Но, все это делают профессиональные программисты, асы своего дела! А я для себя, пока еще никаких преимуществ ООП не почувствовал . Может я до него еще не дорос.

Можете объяснить на простом примере. Есть такая игра "Жизнь" Дж. Конвея. Очень удобна для программирования. Я написал ее в Delphi разбив на ряд процедур (функции).

Одна процедура считает следующее поколение.
Вторая рисует колонию.
Третья создает случайную колонию.
Четвертая отслеживает циклическое повторение в развитии колонии.
Процедура сохранения в файл.
И т.д.

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

Ты сам ответил на свой вопрос.

Разница между ПОП и ООП такая-же как и между коммунизмом и капитализмом.
Коммунизм: всё общее, дети, жены. Эдакий конвеерный подход. В ООП такие вещи имеют аналогии менеджеры. Т.е. идёт себе кучка голых данных по конвееру а её каждая процедура изменяет.
С другой стороны, в ООП прорисовываться некоторая аналогия с западным капиталистическим обществом. Индивидуальность, семья, приватные вещи очень сильно ценяться.

2 Pegas
Ну хорошо, может быть вы правы и я сам ответил на свой вопрос. И все же примера реализации "Жизни" методом ООП не будет? Хотя бы в двух словах, что там взять за объекты и какие там определить события?




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

Ценность и простота ООП становится видна не при создании программы, а при ее расширении. Пример про "Жизнь"? Допустим, есть у нас класс GameField. В нем хранится двухмерный массив (поле для игры) и у него есть открытый метод ProcessTick, в котором содержатся операции для обновления поля (рождение, смерть, ..). Еще у нас есть интерфейс IGUI, содержащий метод Paint(GameField). Из ProcessTick вызывается этот метод. Конкретный GUI реализует IGUI. Т.о. в любой момент мы можем менять GUI, не трогая логику.

В двух словах этого не объяснить. Осознать принципы ООП - вполне реальная задача.

Лучше всего для этого подойдет книга Гради Буча - Объектно-ориентированный анализ и проектирование.

Все понятно, пошел учить С++

Vendigo, можно и в Паскале писать по методологии ООП, мочно и на C++ писать проседуральные программы.
Все дело в походе и какие ограничения накладывает язык.

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

2 boevik, да я знаю что есть Object Pascal и Delphi. Я имел ввиду, что мне, видимо, не хватает знаний и опыта для того чтобы оценить ООП. А посему нужно просто двигаться вперед, не пытаясь заглядывать за горизонт

Имохо, программировать "Жизнь" ООП способом, это сродни использованию танка в роли городского транспорта. И накладно, и неудобно, только шишек набьешь да дороги попортишь.

"К примеру, объект колония" Какие характеристики она имеет?
1. Расположение клеток (основная и исчерпывающая характеристика колонии)
2. Возраст (можно подсчитывать, сколько поколений прошло от изначальной конфигурации)
3. "Зацикленность" (можно запоминать последние поколений 20, и если конфигурация в текущем поколении совпала с каким-нибудь предшествующем, то колония зациклилась)

Методы:
1. Просчитать следующее поколение
2. Записать в файл
3. Считать из файла
4. Нарисовать
5. Создать случайную колонию

В целом, если убрать шелуху, то объект колония имеет одну характеристику - расположение клеток. И три метода - создать колонию, нарисовать колонию и просчитать следующее поколение.

Наследственность и взаимодействие с другими объектами, по-моему, здесь трудно реализовать.
Мой вывод: программа слишком проста для ООП. Проще ходить пешком

А где проходит граница между процедуральным и ООП програмированием?
Какими критериями оперировать для приема решения ООП или процедуры?

Для учебной цели сделать игру "Жизнь" в ООП полне подходящая задача.
Никто не начинает писать программы с сотни-десятков классов.
Так, что начинай с простеньких программ.

Vendigo, правильно
Как я уже говорил,

. То есть как только ты захочешь изменить GUI программы, её правила и т.п., тебе это будет сделать куда проще, чем без ООП.

Изящество ООП проявляется во всем. И при разработке и при перепроектировании.

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

Я имею в виду наиболее наглядно видно . А вообще, согласен. Сам когда-то не понимал плюсов ООП..

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

Это сообщение отредактировал(а) Vendigo - 6.3.2006, 21:07

Лучше напиши Шахматы . Это интереснее и нагляднее продемонстрирует мощь ООП.

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