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

Смотря что понимать под сложными системами. Системы бухгалтерии или складирования? Я бы не назвал такие системы сложными. Эти задачи можно решить и без использования ООП.

Исходя из своей практики я склонен согласиться с автром статьи. Ибо знаю пару ООП проектов в которых ошибок просто туча". (решения тогоже самого проекта например на Oracle Developer дает намного меньше ошибок. Проверено.) Но, если быть точным, То я не знаю что порождает ошибки . ООП или неграмотное его применение.

Здравствуйте, oracle_developer, Вы писали:

[]

OD>Исходя из своей практики я склонен согласиться с автром статьи. Ибо знаю пару ООП проектов в которых ошибок просто туча". (решения тогоже самого проекта например на Oracle Developer дает намного меньше ошибок. Проверено.) Но, если быть точным, То я не знаю что порождает ошибки . ООП или неграмотное его применение.

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

Здравствуйте, oracle_developer, Вы писали:

OD>Смотря что понимать под сложными системами. Системы бухгалтерии или складирования? Я бы не назвал такие системы сложными. Эти задачи можно решить и без использования ООП.

Системы управления предприятием пожалуй одна из наиболее сложных задач, которые приходится решать IT-отрасли.

Извиняюсь перед всеми что организовал эту тему ). Не ту кнопку нажал. Хотел ответить в тему про 25% ошибок. А получилось что создал новую.

Здравствуйте, Alexey Shirshov, Вы писали:

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

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

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

Если на проект затрачено меньше времени и специалисты более низкой квалификации то он стоит меньше .

Читал на днях книгу Ален Голуба . Он заявляет , что на разработку ООП и структурным подходом траиться ~ одинаковое время. А выигрыш иден на сопровождении. Чтобы сказать что ООП эффективнее надо доказать что на сопровождение тратиться меньше денежек.

Здравствуйте, oracle_developer, Вы писали:

OD>Извиняюсь перед всеми что организовал эту тему ). Не ту кнопку нажал. Хотел ответить в тему про 25% ошибок.

Всё равно неплохо получилось.

OD>Это конечно хорошо вы говорите, но мне кажеться что предпочтительней тот подход ,который несет больше прибыли компании.

Совершенно верно.

OD>Если на проект затрачено меньше времени и специалисты более низкой квалификации то он стоит меньше .

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

OD>Читал на днях книгу Ален Голуба . Он заявляет , что на разработку ООП и структурным подходом траиться ~ одинаковое время. А выигрыш иден на сопровождении. Чтобы сказать что ООП эффективнее надо доказать что на сопровождение тратиться меньше денежек.

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

Здравствуйте, oracle_developer, Вы писали:

OD>

OD>Сложные системы сегодня писать без ООП практически не реально, поэтому сложные системы пишутся чаще на С++, чем на "чистом" С, отсюда более частые ошибки в программах, писаных именно на нём. Если бы чаще в качестве языка для них брали Delphi, то ошибок бы было больше в нем

OD>Смотря что понимать под сложными системами. Системы бухгалтерии или складирования? Я бы не назвал такие системы сложными. Эти задачи можно решить и без использования ООП.

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

OD>Исходя из своей практики я склонен согласиться с автром статьи. Ибо знаю пару ООП проектов в которых ошибок просто туча". (решения тогоже самого проекта например на Oracle Developer дает намного меньше ошибок. Проверено.) Но, если быть точным, То я не знаю что порождает ошибки . ООП или неграмотное его применение.

По моему опыту, очень немного программистов (10% — 20%, хотя за репрезентативность выборки не ручаюсь), пользующихся ОО-языками толком представляют себе объектные декомпозиции. Например, регулярно путают роли и типы, не говоря уже об иерархиях наследования алгоритмов (алгоритм, блин, тоже объект!). Естественно, что наивные ОО-декомпозиции срабатывают только однократно — т.е., "сейчас", а затем только запутывают всё что можно и раздувают код. По сути, получаем те же процедурные монолиты, но носящие гордое имя "КЛАСС". Которые ещё и дублируются методом copy/paste. Отсюда и ошибки . Так что, дело тут далеко не в ООП самом по себе.

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

Вот так или примерно так.

Как мне кажется, исходная посылка об ошибках и ООП правильна. Ведь речь идет о больших проектах, об очень больших, по-настоящему больших проектах.

Я только что из топика о FORTRAN и физиках, нелюбящих C++, так что не могу сдержаться: также как они занимаясь небольшими проектами с чисто вычислительной сложностью, обеими руками за FORTRAN и 30-летний опыт, так и здесь проблема, как мне кажется, может я кого обижаю зазря, недопонятой.

Если говорить об очень больших проектах, то всплывают некоторые обвинения, выдвигаемые против ООП.

Сейчас я могу припомнить только один:
* Иерархии классов, особенно хорошо продуманные, для слишком больших систем не позволяют понять поведение отдельного корневого класса без изучения всей иерархии.

И происходит это не из-за чрезмерного использования protected, а оттого, что без protected построить систему просто не удалось бы по причине неоправданного и неограниченного роста количества кода (просто нет программистов, способных все это набить), а автоматическая генерация иногда оказывается лишним источником малопонятных ошибок.
Все это спорно, но, если верить публикациям, на практике так и оказывается.

Здравствуйте, Poudy, Вы писали:

P>Как мне кажется, исходная посылка об ошибках и ООП правильна. Ведь речь идет о больших проектах, об очень больших, по-настоящему больших проектах.

Это о таких, от которых дух захватывает и сердце из груди выскакивает? Или которые делает толпа программистов? Или которые тянутся годами? Или которые "по-настоящему коммерческие"? Извини за шпильку Что назовём "по-настоящему большим проектом"?

P>Я только что из топика о FORTRAN и физиках, нелюбящих C++, так что не могу сдержаться: также как они занимаясь небольшими проектами с чисто вычислительной сложностью, обеими руками за FORTRAN и 30-летний опыт, так и здесь проблема, как мне кажется, может я кого обижаю зазря, недопонятой.

А-а-а. Понятно, откуда пиитика в отношении "больших проектов".

P>Если говорить об очень больших проектах, то всплывают некоторые обвинения, выдвигаемые против ООП.

Ещё раз — что за проекты? Просто очень много людей говорят про "большие проекты".

P>Сейчас я могу припомнить только один:
P>* Иерархии классов, особенно хорошо продуманные, для слишком больших систем не позволяют понять поведение отдельного корневого класса без изучения всей иерархии.

Интересно было бы узнать источник подобного обвинения В другом случае я может и не стал бы наезжать, но попытка опереться на подобное высказывание космического масштаба и космической же глупости... ( (c) проф. Ф.Ф. Преображенский. )

1. Что такое "хорошо продуманные иерархии"?

2. Каковы критерии "хорошей продуманности"?

3. Что такое "слишком большие системы"?

Обвинение очень похоже на маркетинговые бредни, вроде обсуждавшихся в соседней ветке о том, что C++ даёт на 25% больше ошибок. Изобилует обобщениями, сделанными неизвестно на чём, неизвестно кем, неизвестно почему. То есть, — неправомерными обобщениями, ибо не доказана их правомерность. А подобные фишки — излюбленный приём маркетологов.

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

P>И происходит это не из-за чрезмерного использования protected, а оттого, что без protected построить систему просто не удалось бы по причине неоправданного и неограниченного роста количества кода (просто нет программистов, способных все это набить), а автоматическая генерация иногда оказывается лишним источником малопонятных ошибок.

А ты уверен, что речь шла о protected, а не о template?

P>Все это спорно, но, если верить публикациям, на практике так и оказывается.

Да не верь ты таким публикациям! Особенно тем, которые изобилуют взглядами "сверху", "в целом", "в общем" и т.п. Помогает. Верь детальному анализу опыта, интуиции (если есть) и ещё — логике. А подобные публикации обычно создаются с какой-то маркетинговой целью. Можешь же ты доверять 30-летнему опыту FORTRAN в противовес определённой категории "всех".

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

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

Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Это о таких, от которых дух захватывает и сердце из груди выскакивает? Или которые делает толпа программистов? Или которые тянутся годами? Или которые "по-настоящему коммерческие"? Извини за шпильку Что назовём "по-настоящему большим проектом"?

Ну не знаю, там САПР, разные АСУП, вроде R3 и т.д. Т.е. много кода, долго длится, куча программистов и проч.
Миллионы строк взаимосвязанных компонент.

ГВ>Интересно было бы узнать источник подобного обвинения В другом случае я может и не стал бы наезжать, но попытка опереться на подобное высказывание космического масштаба и космической же глупости... ( (c) проф. Ф.Ф. Преображенский. )

ГВ>1. Что такое "хорошо продуманные иерархии"?

ГВ>2. Каковы критерии "хорошей продуманности"?

ГВ>3. Что такое "слишком большие системы"?

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

Здравствуйте, Poudy, Вы писали:

P>Я только что из топика о FORTRAN и физиках, нелюбящих C++, так что не могу сдержаться: также как они занимаясь небольшими проектами с чисто вычислительной сложностью, обеими руками за FORTRAN и 30-летний опыт, так и здесь проблема, как мне кажется, может я кого обижаю зазря, недопонятой.

Непонятно и сравнение языков FORTRAN и С++. Вы сами написали "...проектами с чисто вычислительной сложностью...". FORTRAN — узкоспециализированный язык для вычислительных проектов, С++ язык универсальный, к тому же 30-летний опыт относится, по всей видимости к наработанному матаматическому аппарату вычислений, а не к их реализации. В С++ есть шаблоны, а с помощью них очень удобно реализовывать алгоритмы.

P>* Иерархии классов, особенно хорошо продуманные, для слишком больших систем не позволяют понять поведение отдельного корневого класса без изучения всей иерархии.

А представьте себе изучение того же количества кода без иерархии.

P>И происходит это не из-за чрезмерного использования protected, а оттого, что без protected построить систему просто не удалось бы по причине неоправданного и неограниченного роста количества кода (просто нет программистов, способных все это набить), а автоматическая генерация иногда оказывается лишним источником малопонятных ошибок.

В хорошо продуманной иерархии классов (как указано в предыдущем абзаце) нет неоправданного и неограниченного роста количества кода, иногда есть только сложные схемы наследования. А чем помешали милые безобидные protected — вообще не понятно.

Здравствуйте, Poudy, Вы писали:

P>Ну не знаю, там САПР, разные АСУП, вроде R3 и т.д. Т.е. много кода, долго длится, куча программистов и проч.
P>Миллионы строк взаимосвязанных компонент.

Угу. Про большие системы — понял.

АСУП
(Только ИМХО и личные наблюдения) Здесь применяется не только (а чаще, увы, и не столько) ОО-программирование, сколько чудовищная смесь из какого-нибудь SQL, скриптовых языков, и собственно — C++ (ещё и C может быть примешан). Всё это ещё разколоброжено COM-овскими интерфейсами, уродствами библиотеки MFC (которую объектной-то можно назвать только смеху ради) и прочей ахинеей. Знаю, что Scala некоторое время назад была написана на похожей смеси языков (сейчас, вроде, творится то же самое).

И что? О, да! ОО-программирование здесь определённо уже не в состоянии кого-то спасти.

САПР
За всю Одессу не скажу, но насколько я знаю (Ау, коллеги! Если я ошибаюсь — поправьте!), AutoCAD написан на C/C++. Вообще, надо спросить у тех, кто CAD-ами занимается.

ГВ>>Интересно было бы узнать источник подобного обвинения В другом случае я может и не стал бы наезжать, но попытка опереться на подобное высказывание космического масштаба и космической же глупости... ( (c) проф. Ф.Ф. Преображенский. )

ГВ>>1. Что такое "хорошо продуманные иерархии"?

ГВ>>2. Каковы критерии "хорошей продуманности"?

ГВ>>3. Что такое "слишком большие системы"?

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

Подожди, подожди! Не сваливай в одну кучу всё подряд, а именно — то, что недостатки есть и конкреткный недостаток описанный тобой. Для начала скажи хоть — где именно у Страуструпа в D&E есть указания на те же недостатки (хоть раздел назови, а то я порылся специально — не нашёл ничего подобного). Мне просто не верится, что Страуструп мог сказать такое. ИМХО, или фраза попросту вырвана из контекста... или домыслена.

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

Да что ты как с цепи сорвался!
Такой фанатизм я слышал разве что от Свидетелей Иеговы.

При чем тут написано на C++, пишется на C++, не обходится без C++, и возникающие проблемы? Я сам использую только C++ и C#, смотрю на фортрановцев и VB косо. Это имеет прямое отношение к достоинствам и ни малейшего отношения к недостаткам.

D&E я отдал почитать. Как только вернется, поисщу.

Здравствуйте, Poudy, Вы писали:

P>Да что ты как с цепи сорвался!
P>Такой фанатизм я слышал разве что от Свидетелей Иеговы.

Интересное сравнение, но это к делу не относится. Кстати, такие оценки лучше приватом отправлять. Мой почтовый адрес — в профайле.

P>При чем тут написано на C++, пишется на C++, не обходится без C++, и возникающие проблемы? Я сам использую только C++ и C#, смотрю на фортрановцев и VB косо. Это имеет прямое отношение к достоинствам и ни малейшего отношения к недостаткам.

Честно. Никакого мне дела нет до того, что именно ты используешь и как относишься к фортрановцам и VB. Это не аргумент, и уж тем более, если оправдание, то непонятно перед кем и в чём. Я — не судья, который знает, что такое хорошо и что такое плохо и перед которым необходимо оправдываться. Просто я вижу некорректно сформулированные на мой взгляд аргументы, направленные против концепции самой по себе.

Мне кажется, что некорректная аргументация сама по себе достойна контраргументации. Что я и сделал. Кроме того, в данном споре я выступаю в определённой степени защитником ООП. Если процитированное упоминание о проблемах ООП принадлежат Страуструпу, то значит, Страуструп или сам глупость ляпнул или повёлся у кого-то (чего-то?) на поводу, или были какие-то статистически подтверждаемые основания так говорить. В последнем случае нужно уяснять, каковы именно эти самые статистические основания, а не пытаться огульно переносить обобщение, полученное в одних условиях на все остальные.

А при чём тут C++? Да только при том, что он есть там, где я указал. Хотя, справедливочти ради, нужно упомянуть Java и семейство языков .Net (для АСУП). И ещё более справедливости ради: наличие C++ (Java, .Net) отнюдь не означает применения ООП.

P>D&E я отдал почитать. Как только вернется, поисщу.

Буду благодарен за цитату. Собственно говоря, это — самое интересное.