나는 지금까지 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의 블로그 는 훌륭한 정보 소스입니다.
답변
객체 지향 프로그래밍은 다음을 제공합니다.
- 캡슐화
- 내부 상태의 돌연변이 제어
- 내부 표현으로 결합 제한
- 서브 타이핑 :
- 호환 가능한 유형의 대체 (다형성)
- 클래스간에 구현을 공유하는 조잡한 수단 (구현 상속)
Haskell 또는 Scala의 함수형 프로그래밍은보다 일반적인 형식 클래스 메커니즘을 통해 대체 할 수 있습니다. 가변 내부 상태는 권장되지 않거나 금지되어 있습니다. 내부 표현을 캡슐화 할 수도 있습니다. 좋은 비교는 Haskell vs OOP 를 참조하십시오 .
Norman은 “기능 프로그램에 새로운 종류의 것을 추가하려면 새로운 기능을 추가하기 위해 많은 기능 정의를 편집해야 할 수도있다”고 주장했다. 기능 코드가 유형 클래스를 얼마나 잘 채택했는지에 달려 있습니다. 특정 추상 데이터 유형에 대한 패턴 일치가 코드베이스 전체에 퍼져 있다면 실제로이 문제로 어려움을 겪을 지 모르지만 처음에는 디자인이 좋지 않을 수 있습니다.
EDITED 형식 클래스를 논의 할 때 암시 적 변환에 대한 참조가 제거되었습니다. 스칼라에서 타입 클래스는 변환이 아닌 암시 적 매개 변수로 인코딩되지만 암시 적 변환은 호환 가능한 유형의 대체를 달성하는 또 다른 수단입니다.
답변
-
많은 동시 환경에있는 경우 순수 기능 프로그래밍이 유용합니다. 변경 가능한 상태가 없으면 동시성이 거의 사소합니다. Erlang을 참조하십시오.
-
다중 패러다임 언어에서, 변경 가능한 상태의 존재가 구현 세부 사항이어야하므로 FP가 문제 영역에 적합한 모델 인 경우 일부 기능을 모델링 할 수 있습니다. 예를 들어 Python의 목록 이해 또는 D 프로그래밍 언어의 std.range 를 참조하십시오 . 이들은 함수형 프로그래밍에서 영감을 얻었습니다.