기능적 분해는 실제로 반 패턴입니까?

내가 읽는 동안 당신이 만난 최악의 안티 패턴 , 나는 이 게시물 의 링크를 클릭하여 안티 패턴에 대한 웹 사이트에 착륙했습니다.

그리고 http://sourcemaking.com/antipatterns/functional-decomposition 페이지가 궁금해졌습니다.

이 반 패턴은 얼마나 나쁘고 반 패턴입니까? 요즘에는 OOP 프로그래밍을 주로하고 있지만 Java와 같은 순수한 OOP- 언어 ​​및 이들이 가져 오는 디자인 방식에 대해서는 여전히 꺼려합니다. 그리고 코드를 작성하는 동안 여전히 함수형 프로그래밍의 특성이 있다고 생각합니다.

그리고 이것은 의문을 제기했습니다 .OOP + 기능 스타일을 고수하여 잘못하고 있습니까? 아니면 업계에서 일반적이며 실제로 그렇게 나쁘지는 않습니다.

내가 경험 한 바에 따르면 OOP + Functional 스타일은 순수한 OOP 개발자와 완벽하게 호환되지 않습니다. 그러나 동시에 OOP 개발자는 OOP + 기능 개발에 문제가 있지만, 반론은 OOP 솔루션이 과도하게 설계되어 사용하기가 너무 어렵다는 것입니다. 매우 심각한 버그를 숨길 수있는 사각 지대를 소개했습니다.

그래서, 나는이 주제들에 관해 동료와 토론을했지만 실제로 어떤 방법도 완벽하지 않다는 결론에 도달했습니다. 그리고 나는 여전히 질문에 대답하지 않았습니다.

같은 스레드에있는 다른 게시물 의 링크를 통해 OOP 문제가 강화되었습니다 . 링크는 Java 스타일 OOP http://chaosinmotion.com/blog/?p=622를 봅니다 .

그렇다면 기능 프로그래밍과 OOP를 혼합하는 일반적인 태도는 무엇입니까? 그리고 개발자가 달성하기 위해 노력해야 할 균형은 무엇입니까?

우선, 기능적 프로그래밍은 현재 모든 멋진 아이들이하는 일입니다. 안티 패턴 (Anti-Pattern)은 절차 적 프로그래밍에 대해 실제로 이야기하고 있었으며 (기술이 "절차 분해 (procedural decomposition)"라고한다면 더 명확 할 것입니다.)

안티 패턴은 객체 지향 언어로 절차 코드를 작성하는 나쁜 방법에 대해 이야기했고, 다른 페이지는 자바를 작성하는 것이 었습니다. 나쁜 코드를 작성하십시오.

실제로, 나는 절차 지향적 인 것보다 객체 지향 코드에서 약간의 엔지니어링을 보았습니다.

귀하의 경우에는 세부 사항에 따라 다르며 실제로 절차 스타일로 무엇을하는지 잘 모르겠습니다. 정확하고 명확하며 테스트 가능하며 수정하기 쉽습니다. 코드를 판단하는 기준은 특정 스타일의 순도가 아닌 실제적인 관심사를 기반으로해야합니다. 귀하의 경우 합리적이고 지식이 풍부한 사람들이 그러한 우려에 대해 동의하지 않을 수 있으며 그렇게 할 경우 문제의 진실을 판단하는 객관적인 방법이 없을 것 같습니다.