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

Пока я читал «Наихудшие анти-паттерны, с которыми вы столкнулись» , я щелкнул ссылку в этом посте, чтобы попасть на веб-сайт об анти-шаблонах.

И страница http://sourcemaking.com/antipatterns/functional-decomposition заставила меня задуматься.

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

И это подняло вопрос, я делаю неправильно, придерживаясь функционального стиля ООП +, или это распространено в промышленности и на самом деле не так уж плохо.

Из опыта я знаю, что функциональный стиль ООП + не полностью совместим с чистыми разработчиками ООП. Но в то же время, хотя у разработчиков ООП есть проблемы с функциональной разработкой ООП +, контраргумент состоит в том, что решения ООП довольно часто чрезмерно спроектированы и слишком сложны в использовании, и, по моему опыту, даже не были немного проще, и на самом деле Введены некоторые слепые зоны для ОЧЕНЬ серьезных ошибок, чтобы скрыть.

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

Проблема ООП была также подкреплена ссылкой из другого поста в той же теме. Ссылка смотрит на ООП в стиле Java http://chaosinmotion.com/blog/?p=622

Так каково общее отношение к смешиванию функционального программирования с ООП? И какого баланса разработчик должен стремиться достичь?

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

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

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

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