빈혈 도메인 모델이 C # / OOP에서는 좋지 않은 것으로 간주되지만 F # / FP에서는 매우 중요한 이유는 무엇입니까?

재미와 이익을위한 F # 의 블로그 게시물 에서 다음과 같이 말합니다.

기능적 디자인에서는 데이터와 동작을 분리하는 것이 매우 중요합니다. 데이터 유형은 단순하고 "멍청하다". 그리고 따로 따로, 이러한 데이터 유형에 작용하는 많은 기능이 있습니다.

이것은 동작과 데이터가 결합되는 객체 지향 디자인과 정반대입니다. 결국, 그것이 바로 클래스입니다. 실제로 객체 지향 디자인에서는 동작 외에는 아무것도 없어야합니다. 데이터는 개인 정보이며 메서드를 통해서만 액세스 할 수 있습니다.

실제로 OOD에서 데이터 유형 주위에 충분한 동작이없는 것은 나쁜 것으로 간주되며 이름은 " 빈혈 도메인 모델 "입니다.

C #에서는 F #에서 계속 차용하고 더 기능적인 스타일의 코드를 작성하려고합니다. 어떻게 데이터 / 동작을 분리한다는 아이디어를 빌리지 않고 나쁜 것으로 생각합니까? 단순히 정의가 OOP와 함께 있지 않다는 것입니까, 아니면 C #에서 어떤 이유로 F #에 적용되지 않는 것이 확실한 이유가 있습니까 (실제로 반대로되어 있습니까)?

(참고 : 블로그 게시물의 의견에 동의하지 않을 수있는 개인보다는 오히려 좋고 나쁜 것에 대한 의견을 바꿀 수있는 C # / F #의 차이점에 특히 관심이 있습니다.)

FP가이를 목표로하고 C # OOP가하지 않는 주된 이유는 FP에서 초점이 참조 투명성에 있기 때문입니다. 즉, 데이터가 기능으로 들어가고 데이터가 나오지만 원래 데이터는 변경되지 않습니다.

C # OOP에는 개체 관리를 개체에 위임하는 책임 위임 개념이 있으므로 자체 내부를 변경하려고합니다.

FP에서는 객체의 값을 변경하고 싶지 않으므로 객체에 함수를 포함시키는 것은 의미가 없습니다.

또한 FP에서는 C # OOP에서 허용하는 것보다 함수를 훨씬 일반화 할 수있는 더 높은 종류의 다형성이 있습니다. 이런 식으로 any에 적합한 함수를 작성할 수 a있으므로 데이터 블록에 포함시키는 것은 의미가 없습니다. 그 방법은 특정 종류 의 에서만 작동하도록 단단히 결합합니다 a. 어쨌든 일반적으로 함수를 추상화하는 기능이 없지만 FP에서는 트레이드 오프이기 때문에 이와 같은 동작은 C # OOP에서 모두 잘 일반적입니다.

C # OOP의 빈혈 도메인 모델에서 본 가장 큰 문제는 DTO x가 있기 때문에 중복 코드로 끝나고 4 명의 다른 사람들이 다른 구현을 보지 못했기 때문에 활동 f를 DTO x에 커밋하는 4 가지 함수가 있다는 것입니다 . 메소드를 DTO x에 직접 넣으면이 4 명 모두 f의 구현을보고 재사용합니다.

C # OOP의 빈혈 데이터 모델은 코드 재사용을 방해하지만 FP에서는 그렇지 않습니다. 하나의 함수가 여러 유형에 걸쳐 일반화되어 있기 때문에 함수보다 더 많은 시나리오에서 해당 함수를 사용할 수 있기 때문에 더 큰 코드 재사용을 얻을 수 있기 때문입니다 C #에서 단일 DTO를 작성합니다.

주석에서 지적한 바와 같이 , 유형 추론은 FP가 이러한 다형성을 허용하기 위해 의존하는 이점 중 하나이며, 특히 알고리즘 W 유형 추론 을 통해 Hindley Milner 유형 시스템으로 이를 추적 할 수 있습니다 . 제약 기반의 추론이 추가 컴파일 시간 때문에 철저한 검색에 매우 긴 필요가 있기 때문에 C #을 OOP 형 시스템에서 같은 형식 유추를 피할했다, 여기 자세한 사항 : https://stackoverflow.com/questions/3968834/generics-why -이 경우에는 컴파일러가 유추 할 수없는 형식 인수

빈혈 도메인 모델이 C # / OOP에서는 좋지 않은 것으로 간주되지만 F # / FP에서는 매우 중요한 이유는 무엇입니까?

귀하의 질문에는 귀하가 얻는 답변의 유용성을 제한하는 큰 문제가 있습니다. F #과 FP가 유사하다는 것을 암시 / 가정하고 있습니다. FP는 상징적 용어 재 작성, 동적 및 정적을 포함한 거대한 언어 제품군입니다. 정적으로 형식화 된 FP 언어 중에서도 OCaml 및 SML (F #에는 존재하지 않는)의 고차 모듈과 같은 도메인 모델을 표현하기위한 다양한 기술이 있습니다. F #은 이러한 기능적 언어 중 하나이지만 특히 간결한 것으로 유명하며 특히 고차 모듈이나 고급 유형을 제공하지 않습니다.

실제로 도메인 모델이 FP로 표현되는 방식을 알려 드릴 수 없었습니다. 다른 답변은 Haskell에서 어떻게 수행되는지에 대해 매우 구체적으로 말하며 Lisp (모든 FP 언어의 어머니), ML 언어 군 또는 기타 기능적 언어에는 적용되지 않습니다.

어떻게 데이터 / 동작을 분리한다는 아이디어를 빌리지 않고 나쁜 것으로 생각합니까?

제네릭은 데이터와 동작을 분리하는 방법으로 간주 될 수 있습니다. ML 기능 프로그래밍 언어 제품군에서 나온 제네릭은 OOP의 일부가 아닙니다. 물론 C #에는 제네릭이 있습니다. 따라서 C #이 데이터와 동작을 분리한다는 아이디어를 천천히 빌리고 있다고 주장 할 수 있습니다.

단순히 정의가 OOP에 맞지 않는다는 것입니까?

OOP는 근본적으로 다른 전제를 기반으로하므로 결과적으로 데이터와 행동을 분리하는 데 필요한 도구를 제공하지 않습니다. 모든 실제 목적을 위해서는 제품 및 합계 데이터 유형이 필요하며이를 전달해야합니다. ML에서 이는 통합 및 레코드 유형과 패턴 일치를 의미합니다.

내가 준 예를 확인 하십시오 .

아니면 어떤 이유로 F #에 적용되지 않는 사실이 C #에서 나쁜 구체적인 이유가 있습니까 (실제로 반대입니까)?

OOP에서 C #으로 점프하는 것에주의하십시오. C #은 다른 언어처럼 OOP에 대해 순수하게 접근 할 수있는 곳이 없습니다. .NET Framework는 이제 제네릭, 정적 메서드 및 람다로 가득합니다.

(참고 : 블로그 게시물의 의견에 동의하지 않을 수있는 개인보다는 오히려 좋고 나쁜 것에 대한 의견을 바꿀 수있는 C # / F #의 차이점에 특히 관심이 있습니다.)

C #의 공용체 유형과 패턴 일치가 없기 때문에 거의 불가능합니다. 당신이 가진 모든 것이 망치라면 모든 것이 못처럼 보입니다 ...

비즈니스 응용 프로그램에서는 불변의 값에 대한 패턴 일치가 모든 가능한 경우를 다루기 위해 훌륭하기 때문에 데이터를 숨기고 싶지 않다고 생각합니다. 그러나 복잡한 알고리즘 또는 데이터 구조를 구현하는 경우 ADT (대수 데이터 형식)를 ADT (추상 데이터 형식)로 변환하는 구현 세부 정보를 숨기는 것이 좋습니다.