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

[Активист]

Срач еще тот))

Подняли вечный срач между C и C++ программистами, ООП или не ООП.

А где суть вопроса? Что значит минусы ООП. По сравнению с чем минусы? Историю возникновения С++ почитайте, все отправдет само.

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

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

Когда я только начинал изучать программирование, из умных книжек у меня было два томика "Архитектура процессоров Intel I386", в котором хорошо давались инструкции, весь принцип работы, чистый ASM, инструкции и машинный код, ни ООП, ни ТТД там в помине не было. Подобные книжки, нужно читать, и реализовывать написанное там, что бы понять как работает процессор (даже без математического сопроцессора, инстукции которого кстати в архитектурах i486 были встроены в процессор).

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

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

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

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

 

[atv]

Я всё больше убеждаюсь, что для тебя сам процесс спора важнее его результата.

возмьи любую книжку по OOD и посмотри сколько там букв.

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

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

Но ведь может и не стать, верно?... Этому можно научиться.

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

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

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

 

[fisher]

atv

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

http://lib.ru/SOCFANT/CHAPEK/gazeta.txt
6. Imago (здесь: подмена - лат.) - шестой прием. Заключается в том, что читателю подсовывается некое невообразимое чучело, не имеющее ничего общего с действительным противником, после чего этот вымышленный противник изничтожается. Например, опровергаются мысли, которые противнику никогда и не приходили в голову и которых он, естественно, никогда не высказывал ; ему
показывают, что он болван и глубоко заблуждается, приводя в примеры действительно глупые и ошибочные тезисы, которые, однако, не принадлежат ему.

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

Я полагаю, что существует способ определить это "лишнее", но к сожалению, мне он неизвестен. А поскольку он мне неизвестен - за неимением строгого логически доказательства приведу тебе примеры "артефактов", которые привносит OOP: множественное наследование -> ромб -> множественное наследование интерфейсов. Но самое смешное, что после этих игр труЪ программисты предпочитают тупо делегировать - меньше гемора, подменил и баста.

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

 

[AmdY]

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

 

[fixxxer]

fisher помнится ты в ЖЖ писал про ООП в плане закона преобразования f(r,t) и несоответствия - так я вот щас подумал - это твое f() - это же ФП, практически as is =)

-~{}~ 16.09.10 01:58:

а основная проблема ООП в том что вокруг него слишком много всякой херни. первоначальная то идея очень простая (и нету там никаких вашу мать инкапсуляций-наследований-полиморфизма!)

 

[fisher]

>>твое f() - это же ФП
не совсем, я писал просто о том, что когда "переменные" существуют отдельно от "законов движения" - декомпозиция проще. то есть это и про функциональщину, и про процедурное. для тех кто хочет быт в курсе - ссылка на себя http://raa.livejournal.com/164720.html

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

 

[tenshi]

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

-~{}~ 16.09.10 11:26:

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

 

[whirlwind]

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

 

[Духовность™]

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

 

[tenshi]

небольшая ретроспектива:

была у нас консоль и писали туда строки

print( 'hello world' );

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

print_int( 5 );
print_complex( (complex)[1,2] );

но подумали умные головы: зачем перечислять в имени функции типы параметров, если они и так очевидны из её сигнатуры

function print( int val );
function print( complex val );

и был полиморфизм, и дали ему имя "сопоставление с образом"

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

function print( complex val );
function abs( complex val );
function operator+( complex val, complex another );
function operator-( complex val, complex another );

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

struct complex {
int vector[];
function print();
function abs();
function operator+( complex another );
function operator-( complex another );
}

и была инкапсуляция, и дали ей имя "класс"

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

print( mult( abs( (complex)[1,2] ), 5 ) )

но ясные головы перевернули их и поняли что не такие уж они и страшные

new complex([1,2]) -> abs() -> mult( 5 ) -> print()

и был контекст вызова, и дали ему имя "объект"

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

class point2d {
int vector[];
int function mult( point2d another ){
int collector= 0;
foreach( int i in this -> vector ){
collector+= this -> vector[ i ] * another -> vector[ i ]
}
return collector
}
}

class point3d {
int vector[];
int function mult( point2d another ){
int collector= 0;
foreach( int i in this -> vector ){
collector+= this -> vector[ i ] * another -> vector[ i ]
}
return collector
}
point3d function mult( point3d another ){
// todo: сделать векторное перемножение
}
}

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


class point2d {
int vector[];
int function mult( point2d another ){
int collector= 0;
foreach( int i in this -> vector ){
collector+= this -> vector[ i ] * another -> vector[ i ]
}
return collector
}
}

class point3d extends point2d {
point3d function mult( point3d another ){
// todo: сделать векторное перемножение
}
}

и было наследование, и дали ему имя "ссылка на прототип"

 

[atv]

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

То что ты сейчас написал, это тоже приём ведения дискуссии. И прибегнул ты к нему, так как приёмы Ленина и Жириновского не имели на меня влияния.

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

а декомпозиция - это операция вне-языковая, к OOD не имеющая прямого отношения.

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

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

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

Но самое смешное, что после этих игр труЪ программисты предпочитают тупо делегировать - меньше гемора, подменил и баста.

И? Что ты этим хотел сказать? ООП всё ещё в стадии развития, всё ещё обкатываются новые идеи, и неудачные идеи отбрасываются. А "труЪ программисты", они ведь не бросили ООП, а воспользовались другим приёмом того же ООП "тупо делегировать". Так что ты хотел сказать этим предложением? Или я опять применяю избитый приём? Я дождусь хоть одного ответа на свои аргументы? Или ты так и будешь переводить дискуссию в разные плоскости, и постоянно повторять свои общие фразы из неудачного личного опыта?

На каждое моё "может стать" у тебя ведь всегда найдется "а может и не стать", верно?

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

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

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

-~{}~ 16.09.10 11:22:

tenshi
5 баллов

 

[fisher]

>>Так чего ты надрываешься
надрываешься? не льстите себе просто... очень вкусно

>>Я дождусь хоть одного ответа на свои аргументы

отвечтать можно на вопросы. вот ты на мои не отвечаешь. я спрашиваю, верно? и на это вежливый человек может либо ответить "да", либо ответить "нет", и в крайнем случае добавить "но есть ньюансы". а ты юлишь, взять хотя бы аналогию велосипеда и мотоцикла. мотоцикл a priori содержит ряд преимуществ. они абсолютно все понятны. это такая картинка для тупых - ведь дураку ясно, что мотоцикл круче велосипеда - значит и ооп круче. ну детский сад - эта аналогия не имеет к нашему спору никакого отношения. в твоей голове ооп почему-то относится к другим парадигмам как же как мотоцикл к велосипеду. дейкстре скажи это. а вот если ты уйдешь от притянутых аналогий, ты уже не сможешь привести подобные преимущества С++ над С например, потому что у труЪ программиста всегда найдется пример на голом С как сделать то же самое.

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

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

 

[atv]

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

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

эта аналогия не имеет к нашему спору никакого отношения

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

ты уже не сможешь привести подобные преимущества С++ над С например, потому что у труЪ программиста всегда найдется пример на голом С как сделать то же самое.

Это контр аналогия к аналогии с велосипедом о мотоциклом? Ок. Всё то, что можно сделать на голом С, можно сделать и на голом ассемблере, и даже в машинных кодах. Более того, на чём бы ты не прогаммил, на С, С++ или Лиспе, процессор об этом ничего не знает, он выполняет всё те же машинные коды. Спрашивается, а в чём же разница?... О чём тогда мы здесь дискутируем?

в то время как основные скилы программиста находятся _над_ этим множеством. так понятнее?

Честно говоря нет, твоя мысль совсем не понятна. Приведи, может, пример, о каких основных скилах программиста ты говоришь.

ооп при всех его минусах самая удобная для меня парадигма.

Ба, тогда о чём мы тут дискутируем?... И ты упомянул понятие "удобство". Лёд тронулся?...

 

[fisher]

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

 

[whirlwind]

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

 

[fixxxer]

что же там тогда есть?

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

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

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

наследование ВНЕЗАПНО вообще не имеет отношения (да и если убрать из любого языка наследование, все можно сделать делегированием с тем же успехом)

а зачем это все затяено было, по словам того же Алана Кея:

...to build a computer language that would enable the programmer to look at the host computer not as a serial instruction follower, but as thousands of independent computers, each one able to command the power of the whole machine

и тут уже приходится задумываться, что в этих терминах "объектнее" - современные гибридные ООП-языки типа Java, или функциональные типа Erlang-а =)

 

[fisher]

кстати отличная статья в википедии - внизу по теме топика
ООП

 

[Sherman]

В тему http://www.johndcook.com/blog/2009/07/27/baklav-code/

 

[StUV]

имхо, спор бессмысленный в принципе
каждый начинает с тезиса

<моя задача> требует <конкретная парадигма>

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

в конечном итоге упирается в вопрос чья задача больше, объемлимее, сложнее, ... (и детское "круче").

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

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

 

[Духовность™]

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