Зачем нужно ООП

draw(circle) и draw(rectange) в одной программе (где rectange и circle - переменные с различными структурами)?

а что мешает это сделать без ООП?

ОПП - это один из наборов способов как не писать компилируемые молитвы макаронному монстру

Если во время копиляции неизвестен конкретный тип, то да, ООП для этого. Если в компайл тайме известно что у тебя там rectangle или circle, то достаточно ad-hoc полиморфизма, без динамической диспетчеризации.

ООП придумали писатели UI. там действительно уместно.

Да не только ui, это в любом компонентном фреймворке востребовано.

ООП это когда MapModelTaskManagerPrototypeDatabaseMappingQueue и прочие SetterComposerMapAttributeAdvisorConcreteClone.

ИМХО это изначально было востребовано создателями моделей. Им же удобно просто написать shit(bricks).

...Clone

Вот моя любимкя ссылочка на эту тему: http://c2.com/cgi/wiki?OopNotForDomainModeling

Ты не видел нормального ООП кода, что тут еще скажешь.

так вот кого на прошлой недели побили java-программисты

ООП это когда MapModelTaskManagerPrototypeDatabaseMappingQueue и прочие SetterComposerMapAttributeAdvisorConcreteClone.

Нет, это когда Java головного мозга. Тяжёлая болезнь. Лечится инъекцией K&R.

Зачем нужно ООП

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

Далёк я буду от правды если скажу, что единственная причина появления ООП - нельзя было сказать draw(circle) и draw(rectange) в одной программе

да, далёк. Ты вообще не имеешь никакого понятия об ООП.

А объяснять я тебе не буду, ибо думаю, что оно тебене нужно.

Зачем нужно ООП

ООП - зло и не нужно, конкретно инкапсуляция и наследование - страшное зло. Код превращается в нечитаемую лапшу, производительность падает.

http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Obje...

ООП можно использовать разве что для рисования UI.

ООП это когда MapModelTaskManagerPrototypeDatabaseMappingQueue

ты бредишь?

Причина появления ООП в том, что оно ближе к пониманию человеком.

ООП - зло и не нужно, конкретно инкапсуляция и наследование - страшное зло. Код превращается в нечитаемую лапшу, производительность падает.

пруф будет?

твоя ссылка не пруф.

ООП - зло и не нужно, конкретно инкапсуляция и наследование - страшное зло. Код превращается в нечитаемую лапшу, производительность падает.

Очередной знаток... нечитаемую лапшу можно писать на чем угодно, это не показатель.

твоя ссылка не пруф.

А ты почитать не пробовал, что там по ссылке, или чукча не читатель?

нечитаемую лапшу можно писать на чем угодно, это не показатель.

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

Хотя у ООП есть свои плюсы, конечно, но не стоит им злоупотреблять.

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

В js например толком нету инкапсуляции, и наследование там натянутое, что по этому поводу скажешь? Или то что на том же си можно писать в парадигме ооп тебя не смущает?

А его никто не видел, потому что нормального ООП кода не существует.

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

http://blog.higher-order.com/blog/2008/12/04/no-such-thing/

Чтобы писать ПО современного уровня, в основном прикладного характера. Делать это быстро, использовать только проверенные паттерны проектирования, придерживаться зарекомендовавших себя традиций и правил. А то понапишут глюкодромов всякие ООП-хейтеры, жалкие неосиляторы, а после еще и поддерживать не могут, даже фиксят этот макаронный код неделями, месяцами. Наражает страна всяких индивидов типа: «Я сделаю все через такую хитрую жопу, что все просто ахнут от моей крутости!», а потом людям которым нужно просто отработать и идти гулять с детишками в парк, сидят ночами, изучают шизофренические лабиринты гения.

Или то что на том же си можно писать в парадигме ооп тебя не смущает

А можно не писать, почему меня это должно смущать? На сишке можно как угодно писать, хоть так:

http://eprints.eemcs.utwente.nl/1077/02/book.pdf

Причина появления ООП в том, что оно ближе к пониманию человеком.

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

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

с другой стороны на си можно писать туже самую ооп-лапшу.

Хорошо, заткнет за пояс любую процедурную лапшу на цэ, так тебе будет понятней, я надеюсь.

Вообще-то ООП это Симула, и она была ну ни разу не для UI.

Хорошо, заткнет за пояс любую процедурную лапшу на цэ, так тебе будет понятней, я надеюсь.

Так понятнее, а теперь докажи правильность своего утверждения. Тесты? Статистика? Или это просто твое личное мнение?

далек.

после http://en.wikipedia.org/wiki/Software_crisis 1968 конфа нато

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

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

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

А причина всему этому твое непонимание и нежелание (или невозможность) понять тему.

Что же в твоем понимании ооп, очень интересно, просвети пожалуйста невежду.

http://harmful.cat-v.org/software/OO_programming/

Читать, понимать.

https://ru.wikipedia.org/wiki/%CE%E1%FA%E5%EA%F2%ED%EE-%EE%F0%E8%E5%ED%F2%E8%...

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

ну и да когда А.кей придумал ооп он не думал о.

Нормального понятного массам определеия массам действительно нет. Я ООП понимаю и использую скорее чисто эмпирически на ряду с другими подходами, такими как adhoc полиморфизм, ФП и так далее.

Мне не нужна ссылка на википедию, мне нужно твое понимание ооп.

И главный вопрос, каким образом инкапсуляция и наследование упрощают код? То, что они очень сильно снижают производительность, мы уже разобрались, а как они упрощают код и зачем они вообще нужны?

неа.

не могут преподать математику в школе.

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

вон в середине нулевых в шашке оказалось http://en.wikipedia.org/wiki/Math_wars чем закончилось?

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

наследование не обязано упрощать - надежда на экономии от повторного использования - однако прематур оптимизация и т.п

инкапсуляция это агрегирование и сокрытие.

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

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

сокрытие какбе оберегает от жирных интерфейсов

но всё это имеет смысл для разумных, а не для очередного трафаретного .

Ну и? Просто куча мнений без конкретики, думаю за ооп не меньше найдется.

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

Далёк я

Бесконечно далек. Ты просто путаешь ооп с ООП. Ни страусы ни трупы ни жабы никакого отношения к ООП не имеют.

для не образованных . как и всякий интуитивно понятный интерфейс.

Мне не нужна ссылка на википедию, мне нужно твое понимание ооп.

Мое понимание ооп совпадает с его описанием в википедии.

И главный вопрос, каким образом инкапсуляция и наследование упрощают код?

А каким образом они его усложняют?

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

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

Образованные тупеют и перестают понимать интуитивно понятные интерфейсы?

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

У меня нет никакого желания что то обсуждать с твоими тараканами в голове.

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

т.е когда в проблемной области уже выделены виды, рода, семейства,царства ...

и достаточно чёткие границы если и не между видами то между родами или на край семействами.

и в дизайне С++ и у тогоже Герберта Спенсера позитивиста - прямо сказано что всякая людская классификация той или иной области мира есть просто упрощение без которого дорог анализ этой области.

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