Controller

컨트롤러는 UI 계층으로부터 가장 먼저 메시지를 받는 역할을 담당한다.

Controller 패턴은 다음과 같은 간단한 질문에 답변한다: UI 계층 다음 또는 너머에서 UI 계층으로부터 가장 먼저 메시지를 받는 객체는 무엇인가?

– UML과 패턴의 적용. 17장. 317쪽.

  • 컨트롤러는 수행되어야 하는 작업을 다른 객체에게 위임하는 것이 핵심이다.
  • 컨트롤러는 수행되어야 하는 작업을 스스로 하지 않는 것이 바람직하다.

위임 패턴

컨트롤러 패턴은 위임(delegation) 패턴의 일종이라 할 수 있다.

UI 계층이 애플리케이션 로직을 포함하고 있으면 안 되기 때문에, UI 계층 객체는 작업 요청을 다른 계층에 위임해야만 한다. "다른 계층"이 도메인 계층일 때, Controller 패턴은 객체지향 개발자가 작업 요청을 받는 도메인 객체 위임자를 만들기 위한 일반적인 선택사항들을 요약한다.

시스템은 대개 사람에 의해 작동되는 GUI를 포함하고, 외부 입력 이벤트를 받는다. 외부 입력을 받는 다른 방법에는 호출을 처리하는 통신 스위치 또는 프로세스 제어 시스템의 센서로부터 받는 신호 등과 같은 외부 메시지가 있다.

모든 경우에 이러한 이벤트를 위한 핸들러를 선정해야 한다. 일반적으로 수용될 수 있는 적합한 선택을 하는 데 도움을 주는 Controller 패턴을 고려하라. 1

  • 시스템 오퍼레이션을 컨트롤러가 직접 수행하는 책임을 갖도록 컨트롤러를 만들면 좋지 않다.
  • 시스템 오퍼레이션은 도메인 계층에서 수행되는 것이 적절하다.

주의할 점

팽창된 컨트롤러 (bloated controller)

  • 컨트롤러에 너무 많은 책임을 할당해주면, 낮은 응집도를 갖게 된다. 즉 너무 다양한 작업을 처리하게 된다.
  • 이런 컨트롤러를 팽창된 컨트롤러라 부른다.

controller를 설계할 때 생길 수 있는 일반적인 문제는 한 controller에 너무 많은 책임을 할당하는 것이다. 이런 controller는 High Cohesion 원칙에 위배되어, 낮은 응집력으로 인한 문제점을 유발시킬 수 있다. 1

다음과 같은 경우를 팽창된 컨트롤러라 진단할 수 있다.

  • controller 클래스 1개가 모든 요청을 받는다.
  • controller가 작업을 도메인 객체에 위임하지 않고, 자기 자신이 수행해버린다.
  • controller가 필요 이상으로 다양한 정보를 갖고 있다.
  • controller가 다른 객체에도 있는 정보를 중복으로 갖고 있다.

크레이그 라만은 다음과 같은 해결책을 제안한다.

  1. 더 많은 컨트롤러를 추가한다.
  2. 각 시스템 오퍼레이션에 대한 책임 수행을 다른 객체에게 위임하도록 controller를 설계한다.

참고문헌

  • UML과 패턴의 적용 [3판] / Craig Larman 저 / 김수동 역 / 홍릉과학출판사 / 2005년 12월 10일 3판 1쇄

주석

  1. UML과 패턴의 적용. 17장. ↩ ↩2