Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата MyNameIsIgor @ 10.04.11, 03:19

Однако же, во-первых, эту привязку отслеживает IDE и потому рефакторится легко и непринуждённо, а не дебильным дедовским find/replace.

ох, возможно ненароком вброшу

Цитата Александр Степанов

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

http://blogerator.ru/page/oop_why-objects-have-failed

Цитата DesweR @ 11.04.11, 09:30

ох, возможно ненароком вброшу

Цитата Александр Степанов

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

http://blogerator.ru/page/oop_why-objects-have-failed

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

Сообщение отредактировано: D_KEY - 11.04.11, 09:39

Если бы товарищ Степанов нам ещё и разумную альтернативу предложил, цены бы ему не было.

Цитата Повстанець @ 11.04.11, 09:53

Если бы товарищ Степанов нам ещё и разумную альтернативу предложил, цены бы ему не было.

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

Цитата MyNameIsIgor @ 11.04.11, 10:07

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

Функциональщина не избавляет от ООП.

Цитата Повстанець @ 11.04.11, 09:53

Если бы товарищ Степанов нам ещё и разумную альтернативу предложил, цены бы ему не было.

Цитата

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

Или автор STL говорит чушь?

Добавлено 11.04.11, 10:36

Цитата Повстанець @ 11.04.11, 10:17

Цитата MyNameIsIgor @ 11.04.11, 10:07

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

Функциональщина не избавляет от ООП.

В смысле не избавляет? Ты как о наркотиках говоришь
Вполне можешь писать в функциональном стиле и не использовать ООП. Более того, ООП все-таки императив, как ни крути. Вот если смотреть далее в сторону акторов и агентно-ориентированного программирования, то там есть простор для связи ООП, ФП и ЛП.

Добавлено 11.04.11, 10:38
Немного ближе к теме холивара

Цитата Р.Столлман

ООП ради самой ООП уже давно превратилось в замкнутый круг. Конечно, можно считать C# в .NET 3.5 с более чем 50,000 реализованных классов "венцом эволюции". Добавить в следующей версии .NET ещё миллион классов - что может быть более правильным и более вожделенным, с точки зрения ООП-программиста? Говорите, это и есть то самое бегство от сложности?

Сообщение отредактировано: D_KEY - 11.04.11, 10:38

Цитата D_KEY @ 11.04.11, 10:33

Или автор STL говорит чушь?

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

Цитата Повстанець @ 11.04.11, 10:39

Цитата D_KEY @ 11.04.11, 10:33

Или автор STL говорит чушь?

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

Ну почему же не за что? Есть системы, написанные не в ООП-стиле. Или ОС, системы связи, различные космические аппараты и т.п. не являются примерами сложных систем?
На практике очень часто видно, как ООП приводит к избыточности, перегруженности, неоправданному усложнению системы, а тот же рефакторинг необходим практически всегда. Разве нет?
Кроме того, Степанов говорит, что нужно идти не от классов, а от алгоритмов и вообще действий, а потом уже определять сущности и интерфейсы.

Сообщение отредактировано: D_KEY - 11.04.11, 10:44

Цитата D_KEY @ 11.04.11, 10:43

Кроме того, Степанов говорит, что нужно идти не от классов, а от алгоритмов и вообще действий, а потом уже определять сущности и интерфейсы.

От этого объекты описываемые этими интерфейсами перестанут быть объектами, а система в целом не будет объектно-ориентированной? Собственно, кто мешает так делать, хоть на процедурно-модульном паскале?

Цитата D_KEY @ 11.04.11, 10:43

На практике очень часто видно, как ООП приводит к избыточности, перегруженности, неоправданному усложнению системы, а тот же рефакторинг необходим практически всегда. Разве нет?

Да. Это что то меняет? В какой парадигме эти недостатки отсутствуют?

Цитата D_KEY @ 11.04.11, 10:43

Ну почему же не за что? Есть системы, написанные не в ООП-стиле. Или ОС, системы связи, различные космические аппараты и т.п. не являются примерами сложных систем?

Что то сферическое в вакууме. Есть, к примеру оконная система, GUI одним словом. Можно пример не ООПшной декомпозиции, не превращающей в дикий гиморой её использование. В двух словах, не надо много писать.

Цитата Повстанець @ 11.04.11, 10:50

Цитата D_KEY @ 11.04.11, 10:43

Кроме того, Степанов говорит, что нужно идти не от классов, а от алгоритмов и вообще действий, а потом уже определять сущности и интерфейсы.

От этого объекты описываемые этими интерфейсами перестанут быть объектами, а система в целом не будет объектно-ориентированной? Собственно, кто мешает так делать, хоть на процедурно-модульном паскале?

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

Цитата

Цитата D_KEY @ 11.04.11, 10:43

На практике очень часто видно, как ООП приводит к избыточности, перегруженности, неоправданному усложнению системы, а тот же рефакторинг необходим практически всегда. Разве нет?

Да. Это что то меняет? В какой парадигме эти недостатки отсутствуют?

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

Цитата

Есть, к примеру оконная система, GUI одним словом. Можно пример не ООПшной декомпозиции, не превращающей в дикий гиморой её использование. В двух словах, не надо много писать.

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

Цитата D_KEY @ 11.04.11, 10:59

Рефакторинг активно применяется только в ООП.

С чего бы это вдруг? Рост/развитие любой программы рано или поздно приводит к необходимости рефакторинга независимо от того, на чем она написана.

Добавлено 11.04.11, 12:16

Цитата D_KEY @ 11.04.11, 10:59

Все они касаются проблем, имеющих место исключительно в ООП.

А может они просто описаны в терминах ООП?

Цитата trainer @ 11.04.11, 12:10

Цитата D_KEY @ 11.04.11, 10:59

Рефакторинг активно применяется только в ООП.

С чего бы это вдруг?

Вот это и интересно.

Цитата

Рост/развитие любой программы рано или поздно приводит к необходимости рефакторинга независимо от того, на чем она написана.

Но почему-то о рефакторинге слышно только от ООП-программистов...

Цитата D_KEY @ 11.04.11, 12:17

Но почему-то о рефакторинге слышно только от ООП-программистов...

Т.е. от всех практикующих программистов...

Цитата Повстанець @ 11.04.11, 12:19

Цитата D_KEY @ 11.04.11, 12:17

Но почему-то о рефакторинге слышно только от ООП-программистов...

Т.е. от всех практикующих программистов...

Ничем не подтвержденное высказывание

Цитата D_KEY @ 11.04.11, 10:43

Кроме того, Степанов говорит, что нужно идти не от классов, а от алгоритмов и вообще действий, а потом уже определять сущности и интерфейсы.

а Реймонд говорит, что сначала нужно спроектировать структуры данных, а алгоритмы тогда станут очевидными =)