ООП гораздо полезнее в теории, чем на самом деле

ООП - такой же мыльный пузырь, как "микроядро", "рефакторинг" и "паттерны". Во всех этих случаях новый термины вводится там, где отдельным терминам вообще не место. Сравните со словом "республика". Корейская Народно-Демократическая Республика vs Республика Корея ;)

>новой идеи о том, что ООП гораздо больше полезен на бумаге

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

кто-нибудь оригинал удосужился прочитать?
http://www.devx.com/opinion/Article/26776

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

"
Certainly for the great majority of programmers—amateurs working alone to create programs such as a quick sales tax utility for a small business or a geography quiz for Junior—the machinery of OOP is almost always far more trouble than it's worth.
"

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

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

даже во времена ФОРТРАНа нормальные программеры старались
писать в ООП стиле. ООП - это просто "организация" кода (и мозгов).

> даже во времена ФОРТРАНа нормальные программеры старались
писать в ООП стиле. ООП - это просто "организация" кода (и мозгов).

Товарищ Valeriy_Onuchin, Вы меня извините, но Вы действительно верите в то, что Вы несете? :D Как-то Ваши слова заставляют по-иному посмотреть на последствия вдалбливания ООП в головы несчастных школяров...

> студней начинается и кончается изучением ООП

а, когда ж их еще учить? Тут как с английским/французским,
чем раньше, тем лучше. Преодолел learning curve - и живи, отдыхай :)

>ООП - это просто "организация" кода (и мозгов).

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

а для правильного использования этого нужно купить правильные инструменты(например у Ration Rose :)) и вот эти инструменты позволят вам использовать ООП.

> а, когда ж их еще учить? Тут как с английским/французским,
чем раньше, тем лучше. Преодолел learning curve - и живи, отдыхай :)

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

> Вы действительно верите в то

я упомянул про "нормальных программеров".
К ним я отношу своего учителя - Rene Brun.
Большую часть жизни он прагрaммировал на ФОРТРАНе (последние 13 лет на C++). написал на этом языке такие пакеты, как PAW, HBOOK, Geant3, Zebra и пр.
Лично я считаю, что по вкладу в HEP физику он дотоин Нобелевской премии, потому что ни одно открытие последних 20-30 лет в физике не
обошлось без применения этих программ.
btw, Tim Berners-Lee (http://ru.wikipedia.org/wiki/%D0%91%D0%B5%D1%80%D0%BD%D0%B5%D1%80%D1%81-%D0%9...) работал под его началом ...

Я знаком и с другими выдающимися людьмии и фраза про "ООП стиль" в ФОРТРАНе - не моя.

btw, фраза про "learning curve" - это тоже его (Rene Brun).

Тут два момента, на самом деле. Первый в том, что ООП действительно не надо пихать повсюду, у него есть области применения(довольно мало, кстати, но есть), а вне этих областей ООП не нужно. Второй - ООП в популярных 'ООП' языках(С++, Java, C#) - говно, а не ООП.

Если речь идет об использовании ООП, то все просто. Доступно и школьнику.

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

> я упомянул про "нормальных программеров".

А, ну тогда, конечно. :)

>ООП - это просто "организация" кода (и мозгов).

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

> Причем мозги у всех работают одинаково - абсолютно все люди мыслят объектно, так они устроены от природы,

Смеялсо...

>Смеялсо...

Видимо потому что считаешь описанную мной в предыдущем посте операцию вполне допустимой.

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

КружкаКофе.УменьшитьОбъемКофе.ОтправитьВРот(Мне); ? Что-та не то, да?

у меня есть пример лучше:

двигатель + баки с горючим + планер + сист. управления = самолёт

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

инкапслуляция + наследование + полиморфизм = ООП
но лично я не понимаю, __какие свойства__ позволяют выделить ООП из множество других схем построения систем

Ага. :) 

public static void CatRest() {

  while(NothingToDo()) {

           balls.lick();
           balls.lick();
           if(master.awake()) {
              hungry = true;
              System.out.println("Meow!!!")
        }
   }
}

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

Сильные у тебя аргументы. :) Сразу видно объектно-ориентированного мыслителя. :) Но все-таки, программирование отвечает на вопрос как сделать что-то полезное, а не что бы сделать со стулом, ты не находишь?

>двигатель + баки с горючим + планер + сист. управления = самолёт обычные структуры данных :) самолет - структура, содержащая предыдущие структуры. >новые свойства Некая 'Самолет.Лететь(из, в)' - обычная функция, или даже процедура, 'Лететь(самолет, из, в)', изменяющая координаты структуры данных 'самолет'. Где здесь место ООП, я не вижу. Нет, ну, естественно, можно запихать и сюда, но зачем? Вон, сокеты в операционных системах - казалось бы, объектная модель, а написаны на си, без всяких кривых классов, но и работают нормально, и пользоваться ими удобно. Абстракции - они в голове программиста, а не в ключевых словах, понимаемых компилятором.

>КружкаКофе.УменьшитьОбъемКофе.ОтправитьВРот(Мне.Ноги); ?
>Что-та не то, да?

ага, не то.
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

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

> Прежде чем сделать что-то полезное обычный программист изобретает стул, кружку, состав кофе,

Нафига бы он их изобретал, если для его задачи они не нужны? :) Если твоя программа решает квадратное уравнение, ты сначала напишешь для нее классы Coefficient, Solution, Equation, Discriminant, а потом будешь на всем этом строить алгоритм? ;)

> программист ООП просто строит это из готовых заранее может даже сделанных когда-то им самим вещей

Да. И программист, изначально обученный только такому методу разработки софта, думать алгоритмически вообще не умеет. Вместо ответа на вопрос КАК сделать то, что надо, он думает только в терминах ЧТО сюда присобачить, чтобы получилось то, что надо. И в какой библиотеке это взять. :)

> ООП это очень даже близкий любому человеку принцип

Да. Это не чуждый человеку принцип. И весьма полезный в своей области применимости. Но область эта не покрывает ни всего программирования, ни тем более, всего человеческого мышления, которое значительно ширее. :)

Я думаю, тебе понравился бы объективизм, это такая философская школа. Очень забавная.

>ООП гораздо полезнее в теории, чем на самом деле

ООП полезен уже хотя бы потому, что на консультировании ООП-архитектов можно зарабатывать деньги :) количество buzzword'ов и отсутсвие формальной теории этому лишь способствует

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

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

>Если твоя программа решает квадратное уравнение, ты сначала напишешь для нее классы Coefficient, Solution, Equation, Discriminant, а потом будешь на всем этом строить алгоритм? ;)

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

>Так в этом как раз одна из выгодных сторон FORTRAN - есть уже готовые процедуры, которые не надо изобретать в том числе и для математических вычислений причем уже отлаженных до тебя

fixed :)

Это "выгодная сторона" не ООП, а стандартных библиотек Жабы, Сишарпа и Петона.

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

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

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

Угу. :)

class Equation {

public static void solve() {

System.out.println("Not implemented yet!"):

}
}

Я о чем и говорю. Вместо того, чтобы решать задачу, ООПист ищет, где все уже сделано до него. И оформляет это в своей программе заклинаниями, смысла которых не понимает. Сколько раз мне студни сдавали проги на Джабе, в которых конструкторы были public static и void. А на вопрос, как они себе представляют static void конструктор, обижались, говоря, ну это же перед всеми функциями пишется, значит и тут надо! :)

Ладно, действительно беспредметный разговор. Где-то ООП полезно. Но далеко не везде. У меня все по данному вопросу.

>Это "выгодная сторона" не ООП, а стандартных библиотек Жабы, Сишарпа и Петона

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

>А никто и не заставляет программировать на ассемблере, или даже на Си.

Я не знаю поняли вы или нет - он писал на объектно-ориентированном асме, tasm по моему с версии 3.0 имел объектно-ориентированные расширения но естественно ограниченные.

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

У этих языков самые мощные стандартные библиотеки, удобные для использования (какбэ плевок в сторону пёрла)

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

>автор

>автор комментария, на который я отвечал

fixed

>Где-то ООП полезно.

а где оно полезно?

>У этих языков самые мощные стандартные библиотеки, удобные для использования (какбэ плевок в сторону пёрла)

а так же в сторону Tcl, REBOL, OTP, D (если считать Tango), гамузом всех JVM и .Net-основанных языков (Scala, F#, Nemerle), и прочая и прочая. ну, насчёт бессмысленности фразы о _стандартных_ библиотеках я уже говорил - в контексте треда куда как интересней наличие _библиотек_ в принципе

> а где оно полезно?

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

>Для написания всяких гуевых междумордий

для этой цели ООП - одно из худших возможных решений. ну, таково моё личное мнение. достаточно однажды попробовать сравнить ООП-описание GUI с Tcl/Tk или REBOL/View, чтобы писать ООП GUI больше не хотелось

вместо java/c# подставить jvm/.net языки :)
У Tcl большая библиотека только для гуи-виджетов, насколько я знаю
про D, rebol и otp особо много не слышал, чтобы судить

Вобщем, суть в том, что "все уже есть" это не заслуга ООП.

>> а где оно полезно?

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

Что же вы так узко мыслите.. Возьмите любую специализированную отрасль - чтобы написать что-то вы будете заканчивать еще одно высшее чтобы понять что к чему ? Некоторые просто воспользуются готовыми классами, возможно за деньги. А кто-то заработывает этим.

>Вобщем, суть в том, что "все уже есть" это не заслуга ООП

согласен полностью

>У Tcl большая библиотека только для гуи-виджетов, насколько я знаю

там много чего есть. и виджеты в неё, кстати, вообще не входят - они все в расширении Tk, и к Tcllib отношения не имеют

>Некоторые просто воспользуются готовыми классами
При чем тут ООП?
Готовые библиотеки не только для ОО-языков есть.

> Что же вы так узко мыслите.. Возьмите любую специализированную отрасль - чтобы написать что-то вы будете заканчивать еще одно высшее чтобы понять что к чему ?

А если Вы, батенько, не понимаете, что в Вашей программе к чему, то польза от Вашей программы отрицательная... :)

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

>отсутсвие формальной теории этому лишь способствует

4.2

via http://www.sql.ru/forum/actualthread.aspx?tid=379368&pg=36#5533762 :
http://agp1.nm.ru/
http://www.realcoding.net/article/view/4635
http://www.realcoding.net/article/view/4570

>При чем тут ООП?

ООП тут при том что в этом случае оно как раз лучше других подходов хорошо ложится на решаемую задачу.