no_mkd
일.컴파운드 패턴이란?
형식적으로 컴파운드 패턴은 확실히 여러 패턴의 조합이지만, 이것만으로는 컴파운드 패턴이라고 할 수 없습니다. 다음 정의를 주목하십시오:
여러 패턴을 결합하여 '프레임워크'를 형성하여 일반적인 문제를 해결합니다. '프레임워크'라고 하면 가장 쉽게 떠오르는 것이 MVC 일 것입니다. 실제로 MVC 는 고전적인 컴파운드 패턴입니다.
이.MVC 와 컴파운드 패턴
Model, View, Controller 각각의 역할:
여기서 제어 로직과 애플리케이션 로직 (알고리즘 로직) 의 차이를 강조해 두겠습니다:
- 제어 로직이란 현재 상황에서 어떤 객체의 어떤 메서드를 호출해야 하는지를 판단하는 것입니다.
- 애플리케이션 로직이란 구체적인 객체의 구체적인 메서드의 내부 구현 (복잡한 알고리즘이나 일련의 구체적인 처리) 을 가리킵니다.
(엄밀히 말하면 View 에도 약간의 제어 로직이 포함되어 있습니다 (사용자의 동작에 따라 어떤 Controller 를 호출할지 판단). 물론 일반적으로 이 정도의 로직은 무시합니다)
MVC 의 최대 장점은 표현층 View 와 모델 Model 을 분리하여 설계상의 느슨한 결합 (변화에 대응) 과 코드의 재사용 (View 는 마음대로 교체할 수 있으며, 새로운 View 의 약간의 제어 로직만 변경하면 됨) 을 실현했다는 것입니다.
앞서 MVC 는 컴파운드 패턴의 일종이라고 말했습니다. 어떤 패턴이 조합되어 있는지 함께 살펴보겠습니다:
- 옵저버 패턴: V 와 C 는 모두 M 의 옵저버입니다 (Model 의 상태 업데이트는 V 에게 뷰 업데이트를 알리거나 C 에게 해당 로직 처리를 알립니다).
- 스트래티지 패턴: C 는 V 의 '스트래티지'입니다. 따라서 V 에 포함된 제어 로직은 '스트래티지 선택', 즉 컨트롤러 Controller 를 선택하는 것입니다.
- 컴포짓 패턴: V 의 구현 자체에 컴포짓 패턴이 적용되었습니다 (최상위 컨테이너의 repaint 메서드를 호출하면 컨테이너 내의 모든 컴포넌트가 다시 그려집니다).
MVC 는 여러 패턴을 적용하여 설계상의 일반적인 문제를 잘 해결하므로 컴파운드 패턴이라고 불립니다.
삼.전통적인 MVC 와 Java 로컬 프로그램의 MVC
위에서 볼 수 있듯이 전통적인 MVC 에서는 구체적인 애플리케이션 로직이 M 에 포함되어 있습니다. 즉, 모델 객체는 일련의 속성 (및 getter, setter) 을 가질 뿐만 아니라 관련 데이터 처리 방법도 가져야 합니다.
이는 Java 로컬 프로그램의 MVC 와 다릅니다. Java 프로그램에서는 패키지 package 를 만들어 코드 구조를 계층화합니다. 일반적으로 다음과 같이 합니다:
설명이 필요합니다:
- vo 패키지에는 일반적으로 각 엔티티에서 추상화된 클래스가 포함됩니다 (bean 이라는 패키지 이름을 사용하기도 하지만 의미는 같으며, 엔티티의 속성과 해당하는 getter 와 setter 만 포함하고 애플리케이션 로직은 포함하지 않습니다).
- dao 와 core 는 모두 service 의 보조 계층이며, 세 계층이 함께 Controller 에 매핑됩니다.
Java 로컬 프로그램의 MVC 와 전통적인 MVC 의 최대 차이는 Java 에서 M 이 더 순수 (깨끗) 하여 단순한 값 객체만 포함하고 애플리케이션 로직을 전혀 포함하지 않는다는 점입니다. 거의 모든 로직이 Controller 안에 담겨 있습니다 (다양한 Concrete Service 클래스).
마지막으로:
컴파운드 패턴을 적용한 성숙한 프레임워크는 MVC 하나만 있는 것이 아닙니다. 다른 프레임워크는 아직 접하지 않았으므로 섣불리 논평할 수는 없습니다.
익숙하지 않은 프레임워크를 마주쳤을 때는 먼저 설계적인 관점에서 내부 구현을 간단히 분석해 보는 것이 좋습니다. 예를 들어 어떤 디자인 패턴이 적용되었는지, 각 계층의 기능과 계층 간의 상호작용 등입니다.
기초적인 디자인 패턴을 몇 가지 이해하는 것은 프레임워크를 빠르게 받아들이는 데 도움이 됩니다. 프레임워크의 내부 구현을 이해해야만 그것을 잘 다룰 수 있습니다.
아직 댓글이 없습니다