[토비의 스프링 3.1] 3주차 스터디 - 탬플릿

스터디 날짜 24.07.23.
스터디 범위 3장. 탬플릿

---

3.2.2

탬플릿 메서드 패턴

• 상속을 통해 기능을 확장한다.
  → 상위 클래스에 불필요한 변화가 생기지 않도록 할 수 있으니 객체지향 설계의 핵심 원리인 OCP를 그럭저럭 지킬 수 있다.
  
• 매번 상속을 통해 서브클래스를 만들어야 한다.
• 확장구조가 클래스 설계 시점에서 고정되어 버린다.
  → 관계에 대한 유연성이 떨어진다.
  

전략 패턴

• 클래스 레벨에서는 인터페이스를 통해서만 의존하도록 만드는 패턴이다.
• Context에서 일정한 구조를 가지고 동작하고, 특정 확장 기능은 Strategy 인터페이스를 통해 외부의 독립된 전략 클래스에 위임한다.
  → 복잡한 알고리즘을 바꿔가면서 사용할 수 있다는 것이 핵심
  
• Context가 구체적인 전략 클래스를 직접 알고 있다면 OCP에 잘 들어맞는다고 볼 수 없다.
  → Context를 사용하는 앞단의 Client가 어떤 전략을 사용할지 직접 정해서 Context에 전달하는 방식으로 해결할 수 있다.
  

→ 전략 오브젝트 생성과 컨텍스트로의 전달을 담당하는 책임을 분리하는 과정을 일반화시킨 것이 DI. 즉, DI란 전략패턴의 장점을 일반적으로 활용할 수 있도록 만든 구조인 것.

3.3.2

로컬 클래스

• 클래스 파일이 많아지는 문제를 해결할 수 있다.

💡 중첩 클래스의 종류

• Static Class: 독립적으로 오브젝트로 만들어 질 수 있음
• Inner Class: 자신이 정의된 클래스의 오브젝트 안에서만 만들어질 수 있음
  • 멤버 내부 클래스: 멤버 필드처럼 오브젝트 레벨에 정의됨
  • 로컬 클래스: 메서드 레벨에 정의됨. 로컬 변수를 선언하듯이 선언하면 됨
  • 익명 내부 클래스: 이름을 갖지 않으며 선언된 위치에 따라서 scope를 다르게 가짐

• 특정 메서드에서만 사용되는 클래스라면 로컬 클래스를 바로 정의해서 쓰는 것도 나쁘지 않음
• 내부 메서드는 자신이 정의된 메서드의 로컬 변수에 직접 접근할 수 있다는 장점도 있음. 다만, 외부 변수를 사용할 때는 외부 변수를 반드시 final로 선언할 것!

익명 내부 클래스

• 클래스 선언과 오브젝트 생성이 결합된 형태
• 클래스를 재사용할 필요가 없고, 구현한 인터페이스 타입으로만 사용할 때 유용함
  • 구현한 인터페이스를 생성자처럼 이용해서 오브젝트로 만든다.

    //StatementStrategy -> 인터페이스
    StatementStrategy st = new StatementStrategy() {
    
    	...
    
    };

3.4.2

인터페이스를 사용하지 않고 DI를 적용하는 것은 문제가 있지 않을까?

• 스프링의 DI는 객체의 생성과 관계 설정에 대한 제어권한을 오브젝트에서 제거하고 외부로 위임했다는 IoC라는 개념을 포괄한다.
• 그런 의미에서 인터페이스가 아닌 클래스를 주입했더라도 DI의 기본을 따르고 있다고 이야기할 수 있다.

어떤 경우에 인터페이스가 아닌 클래스를 DI 구조로 괜찮은걸까?

1. 싱글톤으로 등록되어 여러 오브젝트에서 공유해 사용되는 것이 이상적일 때
2. 클래스가 DI를 통해 다른 빈에 의존하고 있는 경우, 오브젝트를 주입받기 위해서라도 마찬가지로 빈으로 등록되어야 한다.

→ 다만, 클래스를 바로 사용하는 코드 구성은 가장 마지막 단계에서 고려해야 한다..

3.5 템플릿/콜백 패턴

• 템플릿: 전략 패턴의 컨텍스트를 의미한다.
  → 고정되는 틀의 로직
• 콜백: 익명 내부 클래스로 만들어지는 오브젝트를 의미한다.
  → 템플릿 안에서 호출되는 것을 목적으로 한다.

3.5. 1 탬플릿/콜백의 동작원리

탬플릿/콜백의 특징

• 탬플릿/콜백 패턴의 콜백은 보통 단일 메소드 인터페이스를 사용한다.
  • 탬플릿의 작업 흐름 중 특정 기능을 위해 한 번 호출되는 경우가 일반적이기 때문
  • ex) DB connection
  • 즉, 콜백은 일반적으로 하나의 메서드를 가진 인터페이스를 구현한 익명 내부 클래스로 만들어진다고 보면 된다.

탬블릭/콜백의 작업 흐름

• 클라이언트의 역할은 탬플릿 안에서 실행될 로직을 담은 콜백 오브젝트를 만들고, 콜백이 참조할 정보를 제공하는 것이다. 만들어진 콜백은 클라이언트가 탬플릿의 메소드를 호출할 때 파라미터로 전달된다.
• 탬플릿은 정해진 작업 흐름대로 작업을 진행하다가 내부에서 생성한 참조정보를 가지고 콜백 오브젝트의 메소드를 호출한다.
• 콜백은 클라이언트 메소드에 있는 정보 + 탬플릿이 제공한 참조정보를 이용해서 작업을 수행하고, 그 결과를 다시 탬플릿에 돌려준다.
• 탬플릿은 콜백이 돌려준 정보를 사용해 작업을 마저 진행한다. 경우에 따라서는 최종 결과를 다시 클라이언트에 돌려주기도 한다.
• 이러한 작업 흐름의 특징
  • 매번 메서드 단위로 사용할 오브젝트를 새롭게 전달받는다.
  • 콜백 오브젝트가 내부 클래스로서 자신을 생성한 클라이언트 메서드 내의 정보를 직접 참조한다.
  • 클라이언트와 콜백이 강하게 결합된다.

-> 탬플릿/콜백은 전략패턴 + DI의 장점을 익명 내부 클래스 사용 전략과 결합한 독특한 활용법이다. 이를 하나의 고유한 디자인 패턴으로 기억해두면 편리하다.