OOP, и это облегчает разработку?

учил бы питон

А что, ты пробуешь что-то большое аля MS Office/OOffice разрабатывать и ООП тебе мешает? А если просто трудно вьезжаешь, то Software Development это не для тебя, лабай что-нить по-проще на PHP/Django/Rails/whatever или таксистом работай, те же деньги платят, а еще и на свежем воздухе, что для здоровья плюс

не надо превращать лор в богадельню по обьектно-ориентированному программированию :-)
в линуксе есть масса более насущных и первостепенных задач

> А если просто трудно вьезжаешь

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

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

Зачем?? Это совершенно не нужно.

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

А ты на бумажечке напиши...:)

А если серьезно, спагетти, как разруха, они не в парадигме, они в голове. ;) Продумай архитектуру приложения, прежде чем начинать кодировать. В частности, пойми, нужно ли тебе для приложения ООП, или нет. От задачи идем, от задачи... :)

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

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

>Так и с подходами в программировании: кого выбрать ООП или процедурный подход? Ответ прост: самое главное не в выборе подхода, а в качестве выходного продукта. А какой подход чихать, лишь бы костюмчик сидел и клиент был доволен.

"Тролль - клирик: С помошью наложения рук и произнесения слов Мудрости способен воскресить любой мертвый флейм и вдохнуть в него новую силу" (С) Guide to Usenet trolls

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

ну и поддержка ООП в Java это далеко не вершина.... :-\

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

для этого придумали документацию

Документация не для Ъ.

Множественное наследование в большинстве случаев не нужно, а для остальных есть интерфейсы.

> а для остальных есть интерфейсы

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

Множественное наследование можно эмулировать. Хоть это и по-дурацки. Кому оно мешает, не понимаю.

> МН, как я понимаю, необходимо для того, чтобы не копипастить код, как собственно и обычное наследование.

Если бы у прогеров был специализированный, тщательно фильтруемый башорг, это была бы фраза месяца.

Разберись сначала в предмете о которым ты пытаешься тут дискуссию вести.

Усложняет. В 99% случаев. Особенно когда индусоподобные лепят ее в каждую дыру, для каждого 2+2 создавая сто классов со множественным наследованием. Тут уже кто-то давал ссылку про то, что вносить изменения в систему, где много наследования и абстрактных классов неоправданно тяжело. Да и накладки, связанные с созданием временных объектов, весьма пагубно влияют на производительность.

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

Возьми Руби или Смалтолк и на нем смотри что такое ООП. Ява грустна.

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

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

Этот тред просто полон ударных фраз :)

>Ява грустна.

Да, стоит только посмотреть на код сервлета и сравнить с cgi-скриптом на ruby/perl/php

> это была бы фраза месяца

И зачем оно по-твоему надо?

> десятки наследований

а кто сказал, что ООП -- лучший подход, и его надо лепить затычкой в каждую бочку?

Наследование не надо лепить просто так туда, где задумывался немного другой смысл. Того же эффекта можно достичь и другими средствами.

Кроме того, что есть такая возможность "отнаследовать" надо ещё и понимать к чему её стоит применять, а к чему -- не стоит (иначе получим слишком "жёсткую" систему, Хрупкость Базового Класса, и т.п.)

Как и с инкапсуляцией пропертями, полиморфизмом вместо типизированных женериков, и т.п.

http://insidecpp.ru/art/8/

http://www.softcraft.ru/paradigm/dhp/dhp02.shtml

http://www.keldysh.ru/gorbunov/p501.htm

http://www.jwz.org/doc/java.html

> Там методы находятся вне класса, это охренеть как удобно

вроде в смоллтоке и Objective C то же самое?

> посмотреть на код сервлета и сравнить с cgi-скриптом на ruby/perl/php

а потом сравнить с HOP и прослезиться )) :

http://hop.inria.fr/usr/local/share/hop/weblets/home/articles/hop-lang/articl...

> И зачем оно по-твоему надо?

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

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

или вот: http://www-sop.inria.fr/mimosa/Stephane.Epardaud/ulm/docs.php

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

Как в процедурных Сях пишут -

хрень_т* хрень = хрень_создать(); хрень_присоединить_другую_хрень(хрень, другая_хрень); хрень_поставить_так(хрень, параметр); хрень_поставить_эдак(хрень, другой_параметр); хрень_поставить_раком(хрень); хрень_удалить(хрень);

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

> ООП - это средство отображения иерархии понятий предметной области на программу.

произвольное отображение произвольной иерархии объектов в "китайской энциклопедии"? :))

Или всё-таки поортогональнее, с разумными интерфейсами и отношениями?

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

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

> ...спагетти, как разруха, они не в парадигме, они в голове. ;)

Во!

В кои-то веки здравомыслящий человек тут закрепился...

:-)

> индусоподобные лепят ее в каждую дыру, для каждого 2+2 создавая сто классов со множественным наследованием.

множественное наследование аватар естественно для индуизма.

Ну во первых, в Лиспе совсем другое ООП. В ObjC/Smalltalk оно основано на сообщениях, посылаемых обьектам. В лиспе метод является скорее описанием действия, которое может быть осуществлено с объектом или набором объектов. Вот здесь есть пара обобщенных высказываний: http://ru.wikipedia.org/wiki/CLOS

>> ООП - это средство отображения иерархии понятий предметной области на программу.

> произвольное отображение произвольной иерархии объектов в "китайской энциклопедии"? :))

Если хочешь сделать так - можно.

> Или всё-таки поортогональнее, с разумными интерфейсами и отношениями?

> Правда в том, что проектировать всё равно надо, просто записать произвольную иерархию кое-как -- не годицца

Спасибо, капитан Очевидность.

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

Я уже говорил, что этот тред полон ударных фраз? :D

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

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

А в Си ООП тоже есть, gobject называется.

>>> произвольное отображение произвольной иерархии объектов в "китайской энциклопедии"? :))

> Если хочешь сделать так - можно.

а если потом этот код придётся поддерживать? (вот тебе ещё одна ударная фраза :P )

(а что не понравилось про наследование экземпляров? для ролевой модели доступа, например оно полезно или 1..N отношений или для похожих параметризаций.. при этом чтобы наследование экземпляров было полезно, надо между параметризациями делать какой-то протокол (систему типов) ну или костыль в виде ООП паттернов ( и шаблонов 2-3й вложенности, как в WTL ))

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

Ну дык Господь упас Линуса от С++ в свое время. А сейчас он и сам судя по его высказываниям понял как сильно ему повезло что g++ был глючен в свое время.

BTW В исходниках Singularity тоже все чисто и гладко, хотя и ООП.

> замыкания в MOP скорее есть, а в смоллтоке -- скорее нет

Я не спец в Смолтоке, но чем блоки кода не замыкания?

MOP - это скорее дополнение к CLOS, я правильно понимаю?

> Это и есть вершина удобства и легкости разработки?

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

> А в Си ООП тоже есть, gobject называется.

Это вообще перл! :) Ради одного этого стОит на ЛОР ходить... Типа "На Луне тоже есть жизнь! Нил Армстронг называется..."

Singularity:

1) Гипер-тормоз, поэтому кому он нужен? Никто не будет платить за железо сервера в 10 дороже.

2) Ограничивает свободу программиста, принуждая использовать ООП.

+1 И какая тогда может быть Singularity?

> ...паттерны посмотри (потом все равно на них забьешь...

О, я, наконец, понял, что не так с паттернами у программистов русской школы...

Как в Германии дело обстоит:

Оригинальный перец (Гамма и Ко) подчеркивал, что паттерны -- не догма. Ок, на это быстро забили, и теперь эти паттерны используют в основном как _способ_договориться_! Это нечто типа UML теперь, чтобы люди друг друга понимали. А реализации их воспринимают лишь на уровне интерфейса, не далее.

>>> произвольное отображение произвольной иерархии объектов в "китайской энциклопедии"? :))

>> Если хочешь сделать так - можно.

>а если потом этот код придётся поддерживать?

Это называется "прищемить х*й дверью и жаловаться, какая неправильная дверь" (c)

> а что не понравилось про наследование экземпляров?

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

>1) Гипер-тормоз, поэтому кому он нужен? Никто не будет платить за железо сервера в 10 дороже.

Кто-то это чудо уже запускал? Под него из софта только юнит-тесты.

>2) Ограничивает свободу программиста, принуждая использовать ООП.

Бгг... Даже в Жаве при желании можно писать чисто в процедурном стиле.

Блоки кода -- они да, замыкания. Не вырывай цитату из контекста: я про то, что по идее вызов метода объекта -- это транзакция, или замыкание. И если в MOP гарантируется, что это замыкание сломать нельзя, то в смоллтоке -- не гарантируется (можно, например, работать с объектом через прокси-объект и что-то там сломать). То есть, "вызов методов посылкой сообщений" имеет больше возможностей, чем MOP, соответственно, между этими возможностями можно (умеючи) вставить клинья и что-то там сломать. Есть правда, протоколы и категории (в ObjC), в которых можно задать интерфейсы, поддерживаемые сообщения (чтобы не сломать), но клинья между ними можно всё равно вставить (и ничего не поделаешь).

А куда ты денешь стандартную библиотеку классов, которую прийдется использовать на каждом шагу? Да и нормальный компилятор не напишешь: видел я как в некоторых языках под жабу ф-ия компилировались в объект типа class function { ... }

угу. Его и в С++ можно сделать, такой AOP, аспектами. Наличие такого протокола (и его интерфейса, вроде рефлексии, целостности) оказывается полезно само по себе.

> И какая тогда может быть Singularity?

Понятия не имею. Ты о чём?