함수형 프로그래밍 대 객체 지향 프로그래밍

나는 지금까지 OO 프로그래밍에 주로 노출되어 왔으며 기능적 언어를 배우기를 고대하고 있습니다. 내 질문은 :

• 언제 객체 지향적 인 기능 프로그래밍을 선택합니까?
• 함수형 프로그래밍이 더 나은 선택의 일반적인 문제 정의는 무엇입니까?

언제 객체 지향적 인 기능 프로그래밍을 선택합니까?

다른 종류의 소프트웨어 진화가 예상되는 경우 :

• 객체 지향 언어는 사물 에 대한 고정 된 연산 세트가있을 때 유용 하며 코드가 발전함에 따라 주로 새로운 사물을 추가합니다. 기존 메소드를 구현하는 새 클래스를 추가하면 기존 클래스를 그대로 유지할 수 있습니다.

• 함수형 언어는 고정 된 사물 집합이있을 때 유용 하며 코드가 발전함에 따라 기존 사물에 대한 새로운 작업 을 주로 추가 합니다. 기존 데이터 형식으로 계산하는 새 함수를 추가하면 기존 함수가 그대로 유지됩니다.

진화가 잘못되면 문제가 있습니다.

• 객체 지향 프로그램에 새로운 작업을 추가하려면 새로운 메소드를 추가하기 위해 많은 클래스 정의를 편집해야 할 수도 있습니다.

• 기능 프로그램에 새로운 종류의 것을 추가하려면 새로운 기능을 추가하기 위해 많은 기능 정의를 편집해야합니다.

이 문제는 수년간 잘 알려져있다. 1998 년 Phil Wadler는이를 "표현 문제"라고 불렀습니다 . 일부 연구자들은 믹스 인과 같은 언어 기능으로 표현 문제를 해결할 수 있다고 생각하지만 널리 받아 들여지는 솔루션은 아직 주류에 미치지 못했습니다.

함수형 프로그래밍이 더 나은 선택의 일반적인 문제 정의는 무엇입니까?

기능적 언어는 트리 형식으로 기호 데이터를 조작하는 데 탁월합니다. 가장 좋아하는 예는 소스 언어와 중간 언어가 거의 바뀌지 않는 컴파일러 (대부분 동일한 내용 )이지만 컴파일러 작성자는 항상 새로운 번역과 코드 개선 또는 최적화 (사물에 대한 새로운 작업)를 추가하고 있습니다. 컴파일 및 번역은 더 일반적으로 기능적 언어를위한 "킬러 앱"입니다.

반드시 두 패러다임 중에서 선택할 필요는 없습니다. 많은 기능 개념을 사용하여 OO 아키텍처로 소프트웨어를 작성할 수 있습니다. FP와 OOP는 본질적으로 직교 합니다.

예를 들어 C #을 보자. 대부분 OOP라고 말할 수 있지만 많은 FP 개념과 구성이 있습니다. Linq 를 고려한다면 Linq가 존재하도록하는 가장 중요한 구성은 본질적으로 기능적입니다 : 람다 식 .

또 다른 예는 F #입니다. 대부분 FP라고 말할 수 있지만 많은 OOP 개념과 구성이 있습니다. 클래스, 추상 클래스, 인터페이스를 정의하고 상속을 처리 할 수 ​​있습니다. 코드를 명확하게 만들거나 성능을 크게 향상시킬 때도 가변성을 사용할 수 있습니다.

많은 현대 언어는 다중 패러다임입니다.

추천 자료

나는 같은 보트 (OOP 배경, FP 학습)에 있기 때문에 정말 감사 한 독서를 제안합니다.

• Jeremy Miller의 일상적인 .NET 개발을위한 기능적 프로그래밍 . C #의 FP에 대한 많은 기술과 실제 사례를 보여주는 훌륭한 기사 (형식이 좋지는 않지만)

• Tomas Petricek의 실제 기능 프로그래밍 . FP 개념을 주로 다루고, 언제 사용해야하는지 설명하려고하는 훌륭한 책. F #과 C # 모두에 많은 예가 있습니다. 또한 Petricek의 블로그 는 훌륭한 정보 소스입니다.

객체 지향 프로그래밍은 다음을 제공합니다.

1. 캡슐화
   • 내부 상태의 돌연변이 제어
   • 내부 표현으로 결합 제한
2. 서브 타이핑 :
   • 호환 가능한 유형의 대체 (다형성)
   • 클래스간에 구현을 공유하는 조잡한 수단 (구현 상속)

Haskell 또는 Scala의 함수형 프로그래밍은보다 일반적인 형식 클래스 메커니즘을 통해 대체 할 수 있습니다. 가변 내부 상태는 권장되지 않거나 금지되어 있습니다. 내부 표현을 캡슐화 할 수도 있습니다. 좋은 비교는 Haskell vs OOP 를 참조하십시오 .

Norman은 "기능 프로그램에 새로운 종류의 것을 추가하려면 새로운 기능을 추가하기 위해 많은 기능 정의를 편집해야 할 수도있다"고 주장했다. 기능 코드가 유형 클래스를 얼마나 잘 채택했는지에 달려 있습니다. 특정 추상 데이터 유형에 대한 패턴 일치가 코드베이스 전체에 퍼져 있다면 실제로이 문제로 어려움을 겪을 지 모르지만 처음에는 디자인이 좋지 않을 수 있습니다.

EDITED 형식 클래스를 논의 할 때 암시 적 변환에 대한 참조가 제거되었습니다. 스칼라에서 타입 클래스는 변환이 아닌 암시 적 매개 변수로 인코딩되지만 암시 적 변환은 호환 가능한 유형의 대체를 달성하는 또 다른 수단입니다.

1. 많은 동시 환경에있는 경우 순수 기능 프로그래밍이 유용합니다. 변경 가능한 상태가 없으면 동시성이 거의 사소합니다. Erlang을 참조하십시오.

2. 다중 패러다임 언어에서, 변경 가능한 상태의 존재가 구현 세부 사항이어야하므로 FP가 문제 영역에 적합한 모델 인 경우 일부 기능을 모델링 할 수 있습니다. 예를 들어 Python의 목록 이해 또는 D 프로그래밍 언어의 std.range 를 참조하십시오 . 이들은 함수형 프로그래밍에서 영감을 얻었습니다.