Чи справді функціональний розпад є антипатерном?

Поки я читав найгірші анти-шаблони, з якими ви стикалися , я натиснув на посилання в цій публікації, щоб ознайомитись на веб-сайті про анти-шаблони.

І http://sourcemaking.com/antipatterns/functional-decomposition сторінка мене здивувала.

Наскільки поганий цей антидіапазон, і чи взагалі є антидіапазон? Тому що, хоча в даний час я займаюся в основному програмуванням OOP, я все ще відчуваю небажання проти чистої мови OOP - усіх мов, як Java, а також методів дизайну, які вони пропонують. І я здогадуюсь, я все ще маю деякі риси функціонального програмування, поки пишу код.

І це викликало питання, чи я помиляюся, дотримуючись функціонального стилю OOP +, чи це поширене в промисловості і насправді не так вже й погано.

Що я знаю з досвіду, це те, що функціональний стиль OOP + не повністю сумісний з чистими розробниками OOP. Але в той же час, хоча у розробників OOP виникають проблеми з функціональною розробкою OOP +, контраргументом є те, що рішення OOP досить часто надмірно розроблені і занадто важкі у використанні, і, з мого досвіду, навіть не було простіше, а насправді представив кілька сліпих плям для ДУЖЕ серйозних помилок, які можна приховати.

Тож, хоч я і мав дискусію з колегою з цих тем, я прийшов до висновку, що жоден із способів насправді не є ідеальним. І у мене все ще питання без відповіді.

Проблема OOP також була підкріплена посиланням з іншої публікації в тій же темі. Посилання розглядає OOP у стилі Java http://chaosinmotion.com/blog/?p=622

То яке загальне ставлення до змішування функціонального програмування з OOP? І який баланс повинен домагатися розробник?

Перш за все, функціональне програмування - це те, що роблять усі класні діти. Anti-Pattern справді говорив про процедурне програмування (було б зрозуміліше, якби методику називали "процедурною декомпозицією", але це не так), і я думаю, що ви теж були.

Антидіаграма розповідала про погані способи написання процесуального коду об'єктно орієнтованою мовою, інша сторінка розповідала про погане написання Java - правда, немає мови настільки фантастичної, що ви можете робити все, що хочете зробити, але не можете написати неправильний код.

На практиці я бачив трохи більше інженерії в об'єктно-орієнтованому коді, ніж процедурний - трохи менше в інженерії і трохи більше над інженерією.

У вашому випадку це залежало б від конкретності, і я не впевнений, що ви насправді робите в процедурному стилі. Це правильно, зрозуміло, перевіряється, легко змінюється тощо? Критерії оцінювання кодексу повинні базуватися на таких практичних питаннях, а не на чистоті одного конкретного стилю. Здається, що у вашому випадку розумні та знаючі люди можуть не погодитись (і зробити це!) Щодо цих проблем, і якщо так, то, мабуть, немає об'єктивного способу визначити істинність справи.