Java 디자인 패턴의 템플릿 메소드 패턴은 운영 알고리즘의 프레임워크를 정의하고 일부 단계를 하위 클래스에 연기하므로 하위 클래스는 알고리즘 구조를 변경하지 않고도 알고리즘의 특정 특정 단계를 재정의할 수 있습니다. 행동 모델
아래와 같이:
실제로 템플릿 방식은 프로그래밍에서 자주 사용되는 패턴이다. 먼저 예를 살펴보겠습니다. 어느 날 프로그래머 A에게 주어진 임무는 다음과 같습니다. 주어진 정수 배열에서 배열의 숫자를 작은 것부터 큰 것 순으로 정렬한 다음 정렬된 결과를 인쇄하는 것입니다. 분석 후 이 작업은 크게 정렬과 인쇄의 두 부분으로 나눌 수 있습니다. 인쇄 기능은 구현하기 쉽지만 정렬이 약간 번거롭습니다. 하지만 A에게는 먼저 인쇄 기능을 완료하고 정렬 기능을 수행할 다른 사람을 찾는 방법이 있습니다.
abstract class AbstractSort { /** * 배열 배열을 작은 것부터 큰 것까지 정렬 * @param array */ protected abstract void sort(int[] array) public void showSortResult(int[] array){ this.sort(array); System.out.print("정렬 결과: "); for (int i = 0; i < array.length; i++){ System.out.printf("%3s", array[i]) } }}A는 글쓰기를 마친 뒤 최근 입사한 동료 B를 찾아 “이미 메인 로직을 작성해 뒀으니 나머지 로직을 구현하면 된다”고 말했다. 그래서 나는 AbstractSort 클래스를 B에게 주고 B에게 구현을 작성하도록 요청했습니다. B가 그것을 넘겨받아 살펴보았는데, 코드는 다음과 같습니다. 10분 안에 완료될 수 있습니다.
클래스 ConcreteSort 확장 AbstractSort { @Override protected void sort(int[] array){ for(int i=0; i<array.length-1; i++){ selectSort(array, i) } } private void selectSort(int[ ] array, int index) { int MinValue = 32767; // 최소값 변수 int indexMin = 0; // 최소값 인덱스 변수 int Temp; index; i < array.length; i++) { if (array[i] < MinValue){ // 최소값 찾기 MinValue = array[i] // 최소값 저장 indexMin = i } index] ; // 두 값 교환 array[index] = array[indexMin] = Temp }}작성한 후 A에게 전달하면 A가 실행합니다.
public class Client { public static int[] a = { 10, 32, 1, 9, 5, 7, 12, 0, 4, 3 } // 기본 데이터 배열 public static void main(String[] args){ AbstractSort s = new ConcreteSort(); s.showSortResult(a) }} 실행 결과:
결과 정렬: 0 1 3 4 5 7 9 10 12 32
잘 작동합니다. 좋아, 임무 완수했어. 예, 이것이 템플릿 메소드 패턴입니다. 이제 막 직장에 들어간 졸업생들은 대부분 B와 비슷한 경험을 했을 것이다. 복잡한 작업의 경우 회사 최고의 사람들이 기본 논리를 작성한 다음 겉보기에 단순해 보이는 방법을 추상적인 방법으로 작성하고 이를 다른 동료에게 개발하도록 맡깁니다. 이러한 업무 분업은 확실한 수준의 프로그래밍 직원이 있는 회사에서 자주 사용됩니다. 예를 들어, 프로젝트 팀에 아키텍트, 선임 엔지니어, 하급 엔지니어가 있는 경우 아키텍트는 일반적으로 많은 수의 인터페이스와 추상 클래스를 사용하여 전체 시스템의 로직을 하나로 묶고 구현 코딩은 다음에게 전달됩니다. 엔지니어는 난이도에 따라 각각 수석 엔지니어와 하급 엔지니어가 수행합니다. 템플릿 메소드 패턴을 사용해 본 적이 있나요?
템플릿 메서드 패턴의 구조:
템플릿 메서드 패턴은 추상 클래스와 상속 구조를 통한 하나(또는 그룹)의 구현 클래스로 구성됩니다. 추상 클래스의 메서드는 세 가지 유형으로 나뉩니다.
1. 추상 메소드 : 상위 클래스에서만 선언되고 구현되지는 않습니다. 대신 해당 하위 클래스에서 사양을 정의한 후 구현합니다.
2. 템플릿 메소드 : 추상 클래스에 의해 선언 및 구현됩니다. 일반적으로 템플릿 메서드는 기본 논리 기능을 완성하기 위해 추상 메서드를 호출하며 대부분의 템플릿 메서드는 최종 유형으로 정의됩니다. 이는 기본 논리 기능이 하위 클래스에서 재정의될 수 없음을 나타냅니다.
3. Hook 메소드 : 추상 클래스에 의해 선언 및 구현됩니다. 그러나 하위 클래스는 확장될 수 있으며 하위 클래스는 후크 메서드를 확장하여 템플릿 메서드의 논리에 영향을 줄 수 있습니다.
추상 클래스의 임무는 논리적 프레임워크를 구축하는 것인데, 이는 일반적으로 숙련된 인력이 작성합니다. 왜냐하면 추상 클래스의 품질이 프로그램의 안정성을 직접적으로 결정하기 때문입니다.
구현 클래스는 세부 사항을 구현하는 데 사용됩니다. 추상 클래스의 템플릿 메소드는 클래스 확장 메소드를 구현하여 비즈니스 로직을 완성합니다. 구현 클래스의 확장 메서드가 단위 테스트를 통과하고 템플릿 메서드가 정확하다면 일반적으로 전체 기능에 큰 오류는 발생하지 않습니다.
템플릿 방법의 장점 및 적용 가능한 시나리오:
확장이 용이합니다. 일반적으로 추상 클래스에서 템플릿 메소드는 소급해서 변경하기 쉽지 않은 부분인 반면, 추상 메소드는 소급하여 변경하기 쉬운 부분이므로 구현 클래스를 추가하면 일반적으로 기능 확장이 용이하다. , 이는 개폐 원칙에 부합합니다.
유지 관리가 쉽습니다. 템플릿 메소드 패턴의 경우 기본 로직이 동일하기 때문에 템플릿 메소드를 사용하지 않으면 동일한 코드가 여러 클래스에 분산될 수 있어 유지 관리가 매우 불편합니다. .
더욱 유연해졌습니다. 후크 메서드로 인해 하위 클래스의 구현은 상위 클래스의 기본 논리 작동에도 영향을 미칠 수 있습니다. 그러나 유연성은 있지만 하위 클래스가 상위 클래스에 영향을 미치기 때문에 Liskov 대체 원칙을 위반하고 프로그램에 위험을 초래합니다. 이로 인해 추상 클래스 설계에 대한 요구 사항이 더 높아졌습니다.
여러 하위 클래스에 동일한 메서드가 있고 이러한 메서드의 논리가 동일한 경우 템플릿 메서드 패턴 사용을 고려할 수 있습니다. 이 모드는 프로그램의 주요 프레임워크는 동일하지만 세부 사항이 다른 상황에도 더 적합합니다.