какие минусы у ООП?

[fisher]

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

-~{}~ 14.09.10 14:03:

>> Уж сколько раз твердили миру, что стоимость проца ГОРАЗДО дешевле, чем стоимость разработчика.
это одно из самых больших заблуждений. ты понимаешь, что есть разница между переходом от одного сервера к двум (переход дешевый) и от тысяче серверов к двум тысячам (переход дорогой)?

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

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

 

[Krishna]

atv
http://tsya.ru

fisher

Значит у вас там в баду хешлукапы узкое место?

-~{}~ 14.09.10 14:14:

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

Пеши ищо

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

Нет, однозначно не зря я никогда не хотел лезть в хайлоад

 

[fisher]

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

-~{}~ 14.09.10 14:20:

Автор оригинала: Krishna
Оказывается повысив уровень абстракции (что означает снижение количества опереруемых алгоритмами сущностей в первую очередь) мы усложняем деятельность программиста. Вот ведь блин! А мужики то и не знали!

ты не понял. качественно моделировать умеет очень мало людей. а так да - дебилу полное раздолье. а если падаван GoF прочтёт - ух, понесёт.

Автор оригинала: Krishna Нет, однозначно не зря я никогда не хотел лезть в хайлоад

да, рановато, наверное.

 

[atv]

[qoute]ну вам, фанатикам, очень сложно ведь что-то объяснить[/QUOTE]
Так же как и вам

сложных задач вообще нет. все задачи - простые. они сложные, пока ты их не понял. а как только ты их понял - тебе осталось их записать.

Почитай определение сложных задач у Буча, почему они, собственно, считаются сложными (извини что ответил в твоей манере)

язык вообще вторичен. но в ооп именно язык выходит на одно из первых мест

Кто тебе сказал? В ООП на первом месте OOD, а язык действительно можно использовать любой, даже не OOP ориентированный, просто неудобно будет.

потому что ооп придумали для дебилов специально

Ну хоть в жопу не послал, как прошлый раз

на ооп дебилы проще достигают результата.

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

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

Ээээ, а как же дебилы? Про них забыли что-ли?

вариантов потонуть или родить чудовищ - в сто раз выше, если он адепт ооп и всё хочет делать по "канонам"

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

ты понимаешь, что есть разница между переходом от одного сервера к двум (переход дешевый) и от тысяче серверов к двум тысячам (переход дорогой)?

Т.е. ты в своей практике постоянно встречаешься с ситуацией, когда нагрузка на сервера возрастает в два раза, при том что уже есть тысяча серверов?

сколько проца отожрет запись $a->b->c понимаешь?

Ну что я могу сказать, очередной раз отослать тебя к литературе по оптимизации. Наибольший результат при оптимизации достигается оптимизацией высокоуровневых алгоритмов. А затем вниз по уровням, всё меньше и меньше. Оптимизация записи $a->b->c даст тебе выигрыш в 0.001%, и положения не спасёт, если у тебя тысяча серверов нагибается.

читай выше про язык. к этому мне добавить нечего.

Погоди, погоди. Я задал конкретный вопрос "ты хочешь сказать, что отказавшись от ООП ты не столкнёшся с такими проблемами?". Ты что, сливать потихоньку начинаешь?

-~{}~ 14.09.10 13:42:

Автор оригинала: Krishna
atv
http://tsya.ru

Ты не юли, ты пальцем покажи...

 

[fixxxer]

запасся попкорном

 

[Ragazzo]

ололо ололо срач ведется тут давно?

 

[fisher]

atv
ты потроллил просто каждое предложение, давай остановимся на самом важном.

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

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

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

 

[dr-sm]

наткнулся тут недавно, на коммент

У меня на последней работе народ стал писать на джаве с хибернейтами, ентерпрайз джавабинсами и прочей хренотенью.

Выглядело это так: на любой чих нужно было написать:
- интерфейс Хрень
- объект ХреньImpl
- интерфейс ХреньManager
- объект ХреньManagerImpl
- объект ХреньAction (не помню, возможно, там был замешан ещё

один интерфейс)
и только тогда гуйные программеры могли начинать писать гуй,

который всем этим пользовался

В общем, я оттеда убежал

 

[atv]

ты потроллил просто каждое предложение, давай остановимся на самом важном.

А зачем было их писать? Написал бы сразу о самом важном. Так не же, тебе драматизма добавить захотелось.

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

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

как ты споришь, смотри. я говорю: в ооп есть такие-то опасности, и это реально проблемы ооп. ты говоришь - это всё решается организационно! а я тебе говорю, что если инструмент проще, если процесс проще, то и организационно всё проще. и всё.

Ура! Краткость сестра таланта! Сразу бы так выражал свои мысли, просто и ясно. А то прямо как в стиле ООП )) (это не сарказм, это шутка, теперь твоя мысль действительно понятнее)

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

Опять же, отошлю тебя к Бучу:

Эксперименты психологов, например Миллера, показывают, что максимальное количество структурных единиц информации, за которыми человеческий мозг может одновременно следить, приблизительно равно семи плюс-минус два [14]. Вероятно, это связано с объемом краткосрочной памяти у человека. Саймон также отмечает, что дополнительным ограничивающим фактором является скорость обработки мозгом поступающей информации: на восприятие каждой новой единицы информации ему требуется около 5 секунд.

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

Как отмечает Дейкстра, "Способ управления сложными системами был известен еще в древности - divide et impera (разделяй и властвуй)" [16]. При проектировании сложной программной системы необходимо разделять ее на все меньшие и меньшие подсистемы, каждую из которых можно совершенствовать независимо. В этом случае мы не превысим пропускной способности человеческого мозга: для понимания любого уровня системы нам необходимо одновременно держать в уме информацию лишь о немногих ее частях (отнюдь не о всех). В самом деле, как заметил Парнас, декомпозиция вызвана сложностью программирования системы, поскольку именно эта сложность вынуждает делить пространство состояний системы

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

 

[fisher]

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

>>твоё отрицание необходимости Объектно-ориентированной
>>декомпозиции выглядит просто странно

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

 

[AmdY]

думаю в вакансии это необходимо, чтобы быть уверенным, что работник не начнёт всё заворачивать в объекты, а затем вооружившись spl заставлять работать их как массивы.

 

[atv]

что же касается какрй-то мнимой объектно-ориентированной декомпозиции, то её не существует. существует просто декомпозиция.

После этого тезиса, первый можно даже пропустить. На каком основании ты объединил две декомпозиции в одну? На чём, по твоему, основывается OOD и OOP? Если есть только одна декомпозиция, как ты пишешь, то значит OOP и процедурный подход это одно и тоже. Или как тебя понимать. Ясность твоего изложения опять снизилась к нулю.

 

[AmdY]

OOP и процедурный подход это одно и тоже

а разве нет? OOП это надстройка над процедурным подходам, дающая более удобный интерфейс для соблюдения объектности (состояниt, инкапсуляция, наследование, интерфейсы...).

 

[whirlwind]

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

Тут легко прослеживается зависимость выбранной методики от объема исходного кода. Я например не вижу никакого смысла городить ООП-огород в программке на сотню строк http://pastebin.com/aCq0cksP - потому что шансов ошибиться в ней мало и на общую целостность системы этот код не влияет. Просто инструмент выбирается под задачу, а не наоборот.

 

[atv]

AmdY
по моему ты уже сам ответил что нет, это не одно и тоже

 

[fixxxer]

Надстройка по реализации, но не по способу мышления.

 

[fisher]

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

 

[atv]

fisher, знаешь, давай не будем на ходу придумывать термины и определения. То что ты написал, это то о чём писал я, используя термины и определения Гради Буча. И опять же непонятны твои претензии без уточнения о чём ты говоришь, про OOD или OOP.

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

Это и есть OOD, вне зависимости от языка. Опять же, если у тебя выполнено OOD, то с какого фига OOP язык и паттерны GoF приведут к тем "ужасным последствиям", о которых ты упоминал выше, по сравнению с не OOP языком?...

В общем, я думаю, понял твою точку зрения, и считаю её не до конца продуманной с твоей стороны.

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

 

[Krishna]

Надстройка по реализации, но не по способу мышления.

Хотел написать то же самое, но потом решил, что без мазы тем, кто уже не один год в программировании и не понимает сути ООП что-то объяснять

 

[fisher]

>>Это и есть OOD, вне зависимости от языка

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

>>Для тебя цена оверхеда выше чем цена удобства
не выше! я просто о ней помню, и говорю, что это реально проблема, а не долдоню, что это "не проблема ооп!".

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