Цитата(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 разбив на ряд процедур (функции).

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

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