+++


Статью прочитал - но не понял.

Пусть у меня есть необходимость задать некую операцию (например "оплата") над двумя классами объектов. Платеж и начисление. При этом может быть несколько типов платежа и несколько вариантов оплаты начисления. К примеру: обычная оплата, оплата из аванса и так далее. И разные классы начислений: обычное начисление, пени/штраф и так далее.

В данном примере, нужно реализовать 2x2=4 варианта. Система живет, появляется новый класс начисления, нужно новое поведение. Оп...ля... уже нужно 2x3=6 вариантов.... Система живет, появляется еще новый класс оплаты. Эквайрингу, сбербанк-бизнес-онлайн, оплата по QR-CODE. Оп... 5x3 = 15 вариантов Функции. Появились новые классы начислений, требуют разнести воду, канализацию, экологию раздельно. 5x6=30 вариантов.

Плохо я себе это представляю, на уровне компилятора.

В классической программе, от такой мешанины получится спагетти код из if'ов, где кол-во if'ов будет __значительно__ меньше полного набора вариантов M x N

В парадигме из ссылки - нужно реализовывать полный набор M x N функций, большинство из которых будет тупым Copy-Paste

Да, примерно это и имел в виду.

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

Взять те же самые Оплаты и Счета, Начисления. Если подходить с позиции ООП и инкапсуляции как минимум есть PaymentDocument, BillDocument, BillLines.

А дальше начинается порнография. В каком из этих объектов я должен реализовывать метод РазнестиОплату (Квитовать) ? Чисто организационно (по рабочим группам), он относится к модулю ПриемПлатежей. НО он так же должен иметь полный доступ к функционалу Bill и BillLines.

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

А кроме квитовки, есть еще такой функционал как Авансы/Переплаты. Где вообще черт ногу сломит (в нашей сущ. системе).

В результате получается:

что часто данные удобно сложить в какие-то ООП-обертки a la DTO: Payment, Bill, BillLines
А весь бизнес функционал унести в какие нибудь Utility class'ы.

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

IMHO. Утрированно конечно

В таблицах то все понятно. Я именно про ООП говорю.

ООП зиждется на постулате инкапсуляции: данные и код которые их обрабатывают должны быть собраны в одном месте

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