ООП - большой пузырь?

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

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

# я основную идею ооп озвучил Одну из основных. И ту видимо на LOR подчерпнул?!

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

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

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

Когда кажется креститься надо.

Абстракция — великая вещь. Сам ооп появился в результате абстрагирования процедурного программирования, имхо. Полиморфизм тоже классно, не нужно в случае си городить указатели на функции и многое другое. А что тебе не понравилось в том, что я про сообщения между сущностями сказал?

Тред был бы неполным без этой ссылочки: http://ideone.com/xW65jJ :3

И как привязать эту таблицу к клиентской либе СУБД? Гвоздями в 10 местах?

Почти так же, как и в C++. Мест будет меньше, так как не надо разбивать на классы (см. ООП - большой пузырь? (комментарий)).

нужно предусмотреть ...

В программе на любом языке.

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

Зачем? Есть функции и константы. Ничего хардкодить не надо. Смотри, например, http://www.postgresql.org/docs/9.4/static/libpq.html

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

Не всегда лёгкий в поддержке. Если, например, поменялся формат чтения таблицы полей в СУБД, то в Си-стиле скорее всего будет функция db_read_fields, в которой будет вся логика. А в ООП, скорее всего будет DBAccessFactory, от которого где-то отнаследована DBAccessPgsql, который половину кода выполняет через методы объекта, полученного из DBStrategyFactory. И вместо одного окна приходится открывать три, чтобы просто понять, что происходит.

У меня был случай, надо было знакомому помочь написать игру Life (студенческая лаба). Писать было лень, хотел скопировать. Гугл выдал исходники на Java. В общем, там было около 25 классов! Хотя логики у программы: массив поля, один алгоритм пересчёта из старого шага в новый и один алгоритм вывода на экран. А в реализации на Java алгоритм пересчёта из старого шага в новый умудрились разнести на 10 классов типа RuleBirth, RuleStillAlive, RuleDead, CopyStrategy, FieldWalker, ...

Код красив, архитектура элегантная... А работает криво, а как починить знает только ниндзя-разраб,

Ты сам себе противоречишь.

как можно, на том же C, отделить абстракцию от конкретных структур данных? Полиморфизм...

http://www.manpagez.com/man/3/qsort/

http://isis.poly.edu/kulesh/stuff/src/klist/

FILE *file;

в частности всё от того, что в говнокоде чёрт ногу сломит.

пофикшено

с колокольни давнего ООПшника, который от этого дерьма подустал

Коммерческое программирование задалбливает. Как любая рутина в принципе. ИМХО.

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

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

BuilderFactoryBeanVisitorAdvisor[j][k][l][m][n][o]

[q][r][t][v][w]"

что эТО???!!LOL

У меня был случай, надо было знакомому помочь написать игру Life (студенческая лаба). Писать было лень, хотел скопировать. Гугл выдал исходники на Java. В общем, там было около 25 классов!

OMFG. Достаточно пары строк: http://www.youtube.com/watch?v=a9xAKttWgP4&fmt=18

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

Да собственно не то чтобы не понравилось, просто в контексте обсуждения суть ООП сводилась к другому, не касаясь сообщений. Я мало себе представляю как они помогут в обсуждаемом частном случае. Более того, применяя метапрограммирование (говорю исключительно за С++) гибкость становится куда больше, чем применяя голый полиморфизм и уж куда больше, чем в случае с «указателями на функции». Если и есть альтернативы ООП в этом из ФП, то я их не знаю.

Вместе с аватаркой - звучит воодушевляюще :)

хе, не обратил внимания, у меня аватарки отключены

Когда кажется креститься надо.

C++ не нужен!

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

А при применении ООП в ещё более трудноподдерживаемую лапшу. Примеры я уже приводил.

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

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

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

Здесь полностью поддерживаю.

1. Правятся не классы, а зависимые от конкретной реализации части кода (если границ нет, то это проблема подхода и архитектуры; выбор и того и другого зависит от принятой концепции ФП или ООП). В реализации ООП место правки одно, описывающее типы полей и таблицы. Больше мест нет, т.к. абстрактный код сам разруливает работу с ними, а т.к. все происходит на этапе компиляции без применения виртуальных методов, то можно ожидать еще и нормальной оптимизации от компилятора. 2. Вот над libpq абстракция сейчас и работает. Причем работает с нативными типами данных, а не с ее OID'ами, и для запросов и для результатов, получая запрошенную таблицу, с которой можно сразу работать без необходимости кастов и перекодирования строк libpq из char/UTF8 в wchar и обратно. аналогично и со всякими POD'ами. 3. Не знаю, что за «формат чтения таблицы полей в СУБД», т.к. пользуюсь libpq и внутренние изменения PostgreSQL меня не волнуют. Приведение пользовательских типов данных к типам СУБД фактически означает написание процедуры конвертора, что одинаково для ФП и ООП и не критично.

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

У тебя жёсткая привязка к libpq? Или всё-таки поддержка разных СУБД? Если последнее, то у тебя (по ООП) должна быть иерархия классов.

«формат чтения таблицы полей в СУБД»

Для MSSQL:

select * from sys.columns WHERE object_id IN (select object_id from sys.tables where name like 'ТАБЛИЧКА')

Для Oracle

select * 
  from user_tab_columns 
  where table_name = 'TABLE'

Разное представление типов и т.д.

1. Нет, но реализована сейчас для постгреса. Иерархия естественно есть, но это вовсе не означает много мест правки.

2. Во первых, мне нужны были простые и определенные запросы, где различий мало (для селекта например, в форме «получить такие-то поля для таких-то полей или диапазонов», т.е. без вложенных и т.п. запросов, хоть и это можно сделать), во вторых, генерирование запросов также отделено от остального кода, и как показала практика реализация довольно простая, т.к. многое в запросах повторяется и части используются повторно.

А исходники открыты или за грифом секретно? Интересно глянуть, что скрывается в контексте обсуждения

Не закрыты, но это на сегодня больше концепт, сделанный в сильно сжатые сроки, чем готовый код. Палиться быдлокодингом пока нет желания, т.к. 1 генерация с кучей недоработок, требующих довольно солидный рефакторинг. Мне тоже интересно что из этого получится, т.к. это вторая попытка осилить БД. В этот раз с boost::mpl.

Когда «5 лет проработала», то там уже пофигу ООП или не-ООП, всё равно, противогаз, собака и миноискатель нужны.

Проблема ООП в том, что уж очень легко свалиться в трэш типа абстрактных фабрик фабрик классов. Мне участия в таком трэше хватило.

Именно поэтому если мне приходится заниматься проектированием сложной херни, я стараюсь следовать unix-like подходу, что «делим всё на автономные куски и общаются они между собой через каналы связи». С этим тоже далеко не всё просто, но меня устраивает больше чем развесистое ООП.

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

Си - точно не кажется. Go/rust/etc более подходящи ИМХО.

Когда «5 лет проработала», то там уже пофигу ООП или не-ООП, всё равно, противогаз, собака и миноискатель нужны.

не нужны 8) ты просто кроме говна ничего и не видел.

Мне участия в таком трэше хватило.

ЧИТД сам не осилил еще и булькал в команде такихже

Именно поэтому если мне приходится заниматься проектированием сложной херни, я стараюсь следовать unix-like подходу,

да вы еще и размножаетесь

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

LOL, подозрительно что-то напоминает. Не объекты/сообщения? То есть, ты уходишь от ООП с помошью написания программ на ООП?

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

уходишь от ООП с помошью написания программ на ООП

Мда. Опять конфликт определений. Классической ООП в стиле smalltalk — идеально (или близко к этому). Паттерны проектирования по мотивам «банды четырёх» — превращают всё в неудобочитаемую кашу. В современных ООП языках паттерны используются чересчур часто.

И, опять же. «общаются» можно трактовать как просто модульность (в смысле Модула/Ада, например), если это просто вызов функций. Можно трактовать как модель акторов (в смысле Erlang), если куски работают одонвременно. Можно трактовать как ООП, если сообщения и их результаты является объектами (в смысле, результатом сообщения может быть кусок, способный принимать сообщения).

+1

Можно трактовать как ООП, если сообщения и их результаты является объектами (в смысле, результатом сообщения может быть кусок, способный принимать сообщения).

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

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

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

Кстати, потом оказалось, что многие паттены на самом деле — антипаттерны, и «так жиить нельзя».

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

В кривых руках отдельных разработчиков ООП точно не виновато.

Многие современные языки прекрасно поддерживают две парадигмы: к примеру Python.

да. «могу копать» и «могу не копать»

Соответственно, в терминологии объектов он описывается более естественно, чем в терминологии структур, функций и коллбэков

Что интересно, сами структуры функции и колбэки превосходно описываются в терминологии объектов, и ООП:)

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

Код сложен, много слоёв абстракций, сложные иерархии наследования, примеси

Ты описал типичный энтерпрайз. ООП здесь ни при чем.

Насчет абстракций: ФП вообще еще большая абстракция, попытка уйти от процедурного машинного кода. Даже твой Си — абстракция над ассемблером, который абстракция над машинным кодом, который абстракция над микрокодом процессора, который...

ахаха, пятница, вечер, лор, ооп, лол

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

Для замыканий не требуется ООП.

ФП — частный случай ООП

class facepalm

чем отличаются делегаты от виртуальных методов и callback ?

Для замыканий не требуется ООП.

Зато замыкания требуются для того, чтобы реализовывать (или имитировать) ООП.

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

Зато замыкания требуются для того, чтобы реализовывать (или имитировать) ООП.

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

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

В большом проекте, если архитектура спроектирована грамотно, ООП позволяет упростить отладку и тестирование

Линус Торвальдс не согласен

Использование C++ и ООП приводит к
...inefficient abstracted programming models where two years down the road 
   you notice that some abstraction wasn't very efficient, but now all 
   your code depends on all the nice object models around it, and you 
   cannot fix it without rewriting your app

...
If you want a VCS that is written in C++, go play with Monotone. Really. 
They use a "real database". They use "nice object-oriented libraries". 
They use "nice C++ abstractions". And quite frankly, as a result of all 
these design decisions that sound so appealing to some CS people, the end 
result is a horrible and unmaintainable mess.

Если пишешь говнокод, который завтра в помойку, то ооп не нужен.

Неверно. Доказано python'ом. Говнокод на нём пишется в разы быстрее, чем на чём-либо ещё. Благодаря ООП.