happyness

• 많은 콤포넌트와 서비스들을 시스템 정보를 억세스해야 함.
• 어플리케이션 콤포넌트는 시스템 정보에 의존적인 프로토톨과 커플링이 존재하지 말아야 함.
• 어플리케이션 콤포넌트는 다른 실행환경에서 동작하고 있는 오브젝트에게 특정 실행환경에 의존적인 오브젝트를 노출시키지 말아야 함.

• 간단한 get 메소드가 정의되어 있는 인터페이를 제공
• 컨텍스트 오브젝트는 특정 프로토콜에 의존적인 클래스의 래퍼런스를 가지고 있다가 데이터 요청이 들어왔을 때 이것을 해당 오브젝트에 위임.
• 특정 프로토콜에 의존적인 오브젝트가 가지고 있는 데이터의 복사본을 가지고 있을 수 있음.
• 컨텍스트 오브젝트는 데이터가 타당한지를 검증하는 로직을 포함할 수 있음.
• 뎅터가 다른 종류의 폼에서 사용될 수 있도록 변환하는 로직을 제공.

• Request Context Map 전략
  ServletRequest 오브젝트의 데이터를 Map 오브젝트로 표현. 이 전략은 ServletRequest 내에 존재하는 데이터를 Immutable Map 타입의 오브젝트로 리턴하는 getParameterMap 메소드를 제공하고 있기 때문에 간단하고 쉽게 구현할 수 있음.
  하지만 이 접근방법은 고객이 원하는 억세스 메소드를 마음대로 제공할 수는 없음.
• Request Context POJO 전략
  컨텍스트 오브젝트를 POJO 로 표현하고, 각 데이터를 리턴하는 getter 메소드를 정의하고, ServletRequest를 파라메터로 가지고 있는 생성자 함수를 정의하고, 생성자 함수에서 ServletRequest 오브젝트 내에 존재하는 데이터를 멤버변수에 초기화하는 동작을 정의.
  POJO 컨텍스트 오브젝트는 특정 데이터에 대해서는 setter 메소드를 가지고 있을 수 있으므로, 컨텍스트 오브젝트를 위한 클래스를 여러 개 정의할 필요가 있음. Request Context Factory 는 어떤 구현 클래스를 이용해 컨텍스트 오브젝트를 생성할 것인지를 결정. 이 결정은 URL괴 컨텍스트 오브젝트 클래스 이름간 매핑을 통해 이루어질 수 있음.
  이 전략은 원하는 Helper Method를 제공할 수 있기 때문에 가장 견고한 방법이지만, 한 가지 단점은 컨텍스트 오브젝트 클래스가 여러 개 필요함.
• Request Context Validation 전략
  이전에 사용한 전략이 어떠한 것이든 상관없이, Request Context 오브젝트는 폼 레벨에서의 데이터를 검증하는 로직을 수행. 이 검증작업은 필요한 모든 데이터가 입력되었는지, 모든 데이터가 정확한 데이터 타입인지와 같은 기본적인 점증 동작들 임.
• Configuration Context 전략
  컨텍스트 오브젝트는 환경 구성 상태를 캡슐화 함. 어떤 경우에는, 컨텍스트 오브젝트에 특정 티어 클래스들이 필요로 하는 데이터들을 통합되어 있을 수 있음. 이 전략의 예로 javax.servlet.jsp.PageContext와 JSTL javax.servlet.jsp.jstl.core.Config 클래스를 볼 수 있음. 이들 클래스들은 다얗난 컨텍스트에 존재하는 클래스들이 다양한 범위에 존재하는 데이터를 억세스할 수 있도록 함.
• Context Object Factory 전략
  건택스트 오브젝트를 생성하기 위해 팩토리를 사용할 경우, 한 장소에서 오브젝트 생성 및 생성되는 오브젝트의 수를 제어할 수 있음.
• Context Object Auto-Population 전략
  프로토콜에 의존적인 오브젝트가 가지고 있는 데이터를 컨텍스트 오브젝트에 패스할 때 한번에 하나의 어트리뷰트를 패스하기 보다 한번에 모든 데이터를 자동으로 복사해주는 코드를 사용할 수 있음. 예를 들어, jsp:setProperty 액션에서 "*" 와일드 카드를 사용할 경우, 빈에 정의되어 있는 모든 setter 메소드를 호출하게 됨. 이 기능은 JSP 페이지에서만 사용할 수 있지만, 이와 같은 기능을 리플렉션 API를 이용해 직접 구현할 수 있음.

• 장점
  특정 프로토콜에 의존적인 클래스와의 커플링을 느슨하게 함으로써 콤포넌트의 재사용성을 높일 수 있음.
  컨텍스트 오브젝트는 ServletRequest 와 같은 특정 프로토콜에 의존적인 오브젝트가 가지고 있는 데이터가 아닌 임의로 테스트하고 하는 데이터로 채울 수 있기 때문에 데스트가 용이함.
  특정 프로토콜에 의존적인 클래스는 사용하고자 하는 기술의 버전이 바뀔 경우 같이 변경되어야 함. Context Object 패턴을 사용할 경우 특정 프로토콜에 의존적인 클래스와 현재 사용하고 있는 기술간 의존도를 줄일 수 있음.
• 단점
  개발되어야 할 코드의 양이 증가.
  데이터 복사본 등이 생성되어야 하므로 수행속도가 약간 감소.

• Intercepting Filter
• Front Controller
• Application Controller
  

happyness Programming/J2EE Patterns Object Context, 프리젠테이션(Presentation) 티어 패턴