По Вашему мнению, имеет ли смысл возня вокруг ООП?

Нет конечно. Какой в ней смысл. Берёшь ООП и используешь, а возня нинужна.

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

Полиморфизм — классно, инкапсуляция — если реализована так, что не мешает unit-тестированию — тоже классно, наследование — опасно.

имеет ли смысл возня вокруг ООП?

Нужно уточнить о чём конкретно речь.

Не кажется ли вам

Нужна суть.

ООПы бывают разные

Оригинальный ооп - местами продуктивная методология. Кроме этого есть ешё, как минимум, языки ооп(обычно с пропорциональной популярности костыльностью); слоган «ооп»; культ ооп; вероятно что-то ещё. У каждого из них и для каждого из жертв свои смыслы, не следует их одной кучей анализировать.

Си или какой нибудь Го

Там дженериков нет!

Наверное, ребята тут считают себя умнее их.

Argumentum ad verecundiam https://ru.wikipedia.org/wiki/Argumentum_ad_verecundiam

Вирт, Столлман, Степанов,... Многие великие критиковали ООП.

Argumentum ad verecundiam https://ru.wikipedia.org/wiki/Argumentum_ad_verecundiam

Ответ в ООП стиле: [Я понимать:Твоя сКачеством:Прекрасно].

Пофикшено.

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

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

предлагай, разрабатывай, пиши...

Как раз сейчас закончил писать абстракцию для БД на С++. Реализация позволяет задавать состав таблиц, полей, умеет валидацию структуры и типов при подключении и т.д., при этом не привязана к конкретной СУБД. Как это можно сделать на С, описывая весь этот зоопарк только в одном хидере и в минимальном составе: имя таблицы, имя поля, нативный тип, тип хранения в БД, не используя ни наследование, ни шаблоны и без приготовления спагетти, приправленных макросами?

Человеку сложно держать в голове несколько объектов. А уровней абстракции, которые мозг способен разворачивать, и того меньше. Ничего не поделаешь, 6 слоев неокортекса.

Ответ в ФП стиле

Ответ в ФП стиле: Мая. Твая. Понимать. Соглашаться.

Ответ в ООП стиле: Я Вас прекрасно понимаю. И польностью согласен с Вашим мнением. Но, хочу заметить, очень часто без ООП никуда. Т.е. все же необходим симбиоз ФП и ООП. Но на деле чаще проявляется «ООП головного мозга». Мая. Твая. Понимать. Соглашаться.

data List a = Nil | Cons a (List a)

length :: List a -> Integer
length Nil = 0
length (Cons x xs) = 1 + length xs

map :: (a -> b) -> List a -> List b
map f Nil = Nil
map f (Cons x xs) = Cons (f x) (map f xs)

...more 1000 definitions of list operations here ...

параметрическая полиморфизма, натяльника.

---------- *** -----------

ООП

MyList := List clone

И в частности всё от того, что в ООП чёрт ногу сломит.

это оксюморон. ООП — это средство преодоления сложности системы. Сделать простое простым, а сложное — возможным(С).

Ответ в ООП стиле: [Я понимать:Твоя сКачеством:Прекрасно].

Ответ в ООП стиле: [Я понял. Ты ниасилил. Печально...]

//finally fixed

Эпический. Ему еже 4 года. В своё время сам пытался его пофиксить, но очень быстро заблудился во всех этих абстракциях.

все же необходим симбиоз ФП и ООП

Кстати, нет такой необходимости. ФП — частный случай ООП.

Как это можно сделать на С, описывая весь этот зоопарк только в одном хидере и в минимальном составе: имя таблицы, имя поля, нативный тип, тип хранения в БД

struct tb table = {"table-name",
                    {{"f1", DB_VARCHAR, T_STRING, STORE_YES},
                     {"f2", DB_INTEGER, T_INT, STORE_NO}}};

смотрите, анонiмус!

more 1000 definitions of list operations here

Либа же, и в фп будет так же:

MyList := List clone

Яйцо частный случай курицы?

Правильная цитата. Вот только на практике не всегда все так радужно,говнокода в стиле ооп хватает, примеров, когда применение некой методики усложняет решение - тоже.

Кстати, цитата применима к любой методике вообще, ооп тут частный случай.

не получилось

ППКС

Яйцо частный случай курицы?

Не. Любая ФП-абстракция выразим в рамках чистого ООП. А наоборот — не выйдет.

Любая ФП-абстракция выразим в рамках чистого ООП

Это ложь.

А наоборот и не нужно. Это же надстройка.

не получилось

У мартышки с очками тоже не получилось:)

У мартышки с очками тоже не получилось:)

как у анонiмуса с ФП, да

Одна из проблем ООП: too many abstraction layers. ;)

Это проблема не ООП, а пишуших на нем.

Онанизмус не мог пройти мимо такого треда.

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

тогда давай и вторую сразу...

полностью копипаста такова: в ооп любая проблема решается введением дополнительного уровня абстракции... кроме количества уровней абстракции

кроме количества уровней абстракции

нет никакого ограничения на количество уровней абстракции. Это проблема?

Нет, не пузырь.

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

нет: ООП - большой пузырь? (комментарий)

количество уровней зависит от навыков. beastie в этом смысле непоказателен, ибо неосилятор ооп :)

полностью копипаста такова: в ооп любая проблема решается введением дополнительного уровня абстракции... кроме количества уровней абстракции

Заодно краткая истори этой пасты

A famous aphorism of David Wheeler reads: All problems in computer science can be solved by another level of indirection;[2] this is often deliberately mis-quoted with «abstraction» substituted for «indirection». It is also sometimes misattributed to Butler Lampson. Kevlin Henney's corollary to this is, "...except for the problem of too many layers of indirection."

Ну хорошо...И как привязать эту таблицу к клиентской либе СУБД? Гвоздями в 10 местах? А еще нужно предусмотреть конвертирование значений, т.к. не всегда строками и целыми можно обойтись (а еще различное кодирование символов, хранение бинарных структур с различным порядком байт), да и результаты с либы могут быть например в виде строк (в том числе и числа),а еще генерацию запросов (или их тоже подвязывать для каждой таблицы отдельно) и результатов запросов. И так, придется хардкодить во всех местах каждый раз, когда что-либо изменяется. Другой вариант ООП - один раз описал все абстракции и дополнил недостающими данными о требуемой структуре и типах, получив весь слой абстракции работы с БД, при этом легко изменяемый в едином месте. Да, абстракции довольно сложны для понимания, но зато получаем легкий в поддержке прикладной уровень.

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

аффтар пьян

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

Да тут у многих какой-то кризис в программировании. ТС'у: Ну нравится ФП - кодь на Go - кто не даёт? Многие современные языки прекрасно поддерживают две парадигмы: к примеру Python.

ооп характеризуется взаимодействием сущностей посредством отправки сообщений друг другу xDxDxD

Что есть сущность для ООП?

учи матчасть

в данном контексте, объект, очевидно.

...

жООПа головного мозга.

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

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

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

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