일류 함수가 전략 패턴을 대체합니까?

전략 디자인 패턴은 종종 부족 언어로 일류 기능을위한 대용품으로 간주됩니다.

예를 들어 기능을 객체에 전달하고 싶다고 가정 해보십시오. Java에서는 원하는 동작을 캡슐화하는 다른 객체를 객체에 전달해야합니다. Ruby와 같은 언어에서는 기능 자체를 익명 함수 형태로 전달하면됩니다.

그러나 나는 그것에 대해 생각하고 있었고 전략은 단순한 익명의 기능보다 더 많은 것을 제공하기로 결정했습니다.

객체가 메소드가 실행되는 기간과 독립적으로 존재하는 상태를 유지할 수 있기 때문입니다. 그러나 익명 함수 자체는 함수 실행이 완료되는 순간 존재하지 않는 상태 만 유지할 수 있습니다.

일류 함수를 지원하는 객체 지향 언어에서 전략 패턴은 함수를 사용하는 것보다 이점이 있습니까?

언어가 함수에 대한 참조를 지원할 때 ( Java는 버전 8 이후 ) 전략을 대체하는 좋은 대안이 될 수 있습니다. 일반적으로 구문이 적은 동일한 것을 표현하기 때문입니다. 그러나 실제 객체가 유용 할 수있는 경우가 있습니다.

전략 인터페이스에는 여러 가지 방법이있을 수 있습니다. RouteFindingStragegy서로 다른 경로 찾기 알고리즘을 캡슐화 하는 인터페이스 를 예로 들어 봅시다 . 다음과 같은 메소드를 선언 할 수 있습니다.

• Route findShortestRoute(Node start, Node destination)
• boolean doesRouteExist(Node start, Node destination)
• Route[] findAllPossibleRoutes(Node start, Node destination)
• Route findShortestRouteToClosestDestination(Node start, Node[] destinations)
• Route findTravelingSalesmanRoute(Node[] stations)

그런 다음 전략으로 모두 구현됩니다. 일부 경로 찾기 알고리즘은 이러한 사용 사례 중 일부에 대한 내부 최적화를 허용 할 수도 있고 그렇지 않을 수도 있으므로 구현자가 이러한 각 메소드를 구현하는 방법을 결정할 수 있습니다.

또 다른 경우는 전략에 내부 상태가있는 경우입니다. 물론 일부 언어에서는 클로저에 내부 상태가있을 수 있지만이 내부 상태가 매우 복잡해지면 클로저를 본격적인 클래스로 승격시키는 것이 더 우아해 지기도합니다.

익명 함수가 함수 실행이 완료되면 존재하지 않는 상태 만 유지할 수 있다는 것은 사실이 아닙니다.

Common Lisp에서 다음 예제를 보자.

(defun number-strings (ss)
  (let ((counter 0))
    (mapcar #'(lambda (s) (format nil "~a: ~a" (incf counter) s)) ss)))

이 함수는 문자열 목록을 가져 와서 목록의 각 요소 앞에 카운터를 추가합니다. 예를 들어, 호출

(number-strings '("a" "b" "c"))

준다

("1: a" "2: b" "3: c")

이 함수는 number-strings내부적으로 함수를 counter호출 할 때마다 재사용되는 상태 (카운터의 현재 값)를 유지 하는 변수와 함께 익명 함수를 사용합니다 .

일반적으로 클로저는 한 가지 방법으로 만 객체로 생각할 수 있습니다. 또는 객체는 동일한 닫힌 변수를 공유하는 클로저 모음입니다. 따라서 클로저 대신 객체를 사용해야하는 경우가 있는지 확실하지 않습니다. 두 가지가 다른 관점에서 동일한 패턴을 보는 방법이라고 주장합니다.

특히 전략 패턴에는 메소드가 하나만있는 오브젝트가 필요하므로 클로저가 작업을 수행해야합니다. 그러나 필립이 대답에서 관찰 한 바와 같이 상황 (복잡한 상태) 및 프로그래밍 언어에 따라 객체를 사용하여 더 우아한 솔루션을 얻을 수 있습니다.

두 디자인이 동일한 문제를 해결할 수 있다고해서 서로를 직접 대체한다는 의미는 아닙니다.

함수형 프로그램에서 상태를 추적해야하는 경우 언어에서 허용하더라도 닫힌 변수를 변경하지 않습니다. 하나의 상태를 인수로 사용하고 새 상태를 반환 값으로 반환하는 함수를 호출 할 수 있습니다.

아키텍처는 매우 다르게 보일 것이지만 동일한 목표를 달성 할 수 있습니다. 한 패러다임의 패턴을 다른 패러다임에 직접 적용하려고하지 마십시오.

전략은 반복되는 특정 문제를 해결하기위한 유용한 방법 인 개념 입니다. 언어 구성이 아니며 구현 형태에 관한 것도 아닙니다 . 클로저를 사용하여 전략을 언젠가 구현하고 다음 날 옵저버를 구현할 수 있습니다.

용어 전략은 간결하게 당신의 의도를 표현하는 다른 프로그래머들과의 대화에서 주로 유용합니다. 마법은 없습니다.