[Object Oriented S/E] Chapter 10 - Object Interaction Modeling

# 범위

251 page ~

# 내용

## 10.1 WHAT ARE DESIG PATTERNS?

• [10.1 디자인 패턴은 자주 만나게 되는 설계 문제에 대한 해결책의 추상화이다]
• 디자인 패턴을 통해서 비슷한 디자인 문제를 해결할 수 있다.

## 10.2 WHY DESIGN PATTERNS?

• 패턴은 재사용 가능한 요소이다.
• 패턴을 결합하여 크고 복잡한 디자인 문제를 해결 할 수 있다.
• 패턴은 팀 구성원간의 의사소통을 향상시킨다.
• 패턴은 소프트웨어 시스템의 동작과 구조를 증가시킨다.
• 결과적으로 패턴은 소프트웨어의 생산성과 퀄리티를 향성시키며, COST와 TIME을 감소시킨다.

## 10.3 SITUATION-SPECIFIC AND RESPONSIBILITY-ASSIGNMENT PATTERNS

두개이상의 패턴을 무한히 결합하여 문제를 해결할 수 있다.

싱글톤,생성패턴, 등등에 대한 설명

## 10.4 PATTERN SPECIFICATION ( 패턴 규격 )

• 이름과 종류
• 사양
• 디자인
• 이점 및 문제
• 지침
• 관련 패턴
• 용도

## 10.5 THE CONTORLLER PATTERN

• 사용자 인터페이스와 비즈니스 객체(로직)이 서로 영향을 미치지 않고 독립적으로 변경 될 수 있는 소프트웨어 시스템을 설계하는 방법

### 10.5.1 A Motivating Example

• 1. presenatation과 business objects간의 Tight coupling
• Checkout GUI가 Loan object를 만들고 isAvailable()함수를 호출하고 set Available(false)함수를 호출하는데 이러한 것은 긴밀한 결합을 만든다.
• 긴밀한 결합은 객체의 변경이 프레젠테이션의 변경을 필요로 할 수 있다.( 그반대의 경우도 해당 ) 좋지 않다는 뜻이다.
• 2. 프레젠테이션은 actor의 요청을 처리해야한다.
• backgroud의 processing이 필요한 actor의 요청을 프레젠테이션에서 처리하는데 이렇게 하면 안된다.
• 프레젠테이션은 유저 인터페이스를 보여주는 역할을 하기 때문에 엑터의 프로세스를 수행할 책임이 없다.
• 모든 측면에서 동시에 다루기 보다는 관심의 분리가 필요하다.
• actor의 요청을 처리하는 것은 프레젠테이션이 아닌 비즈니스 객체에서 할당되어야 한다.
• 3. 프레젠테이션에 너무 많은 책임이 할당 됐다.
• 높은 응집력 원칙에 위배된다.

 

### 10.5.2 What is a Controller?

• 프레젠테이션과 비즈니스 객체를 분리시킨다. 
• 그리하여 하나의 변경사항이 다른 하나에 영향을 미치지 않는다.
• 소프트웨어의 유지보수성을 향상시킬 수 있다.

 

### 10.5.3 Applying the Controller Pattern

• 프레젠테이션과 비즈니스 객체사이에 컨트롤러를 배치시킨다.
• 프레젠테이션에서의 비즈니스 로직이 제거되고 컨트롤러에 할당된다.
• 1. 변화를 위한 설계, 체크아웃 컨트롤러의 인터페이스와 상호 작용 동작이 변경되지 않는다면 비즈니스 로직이나 비즈니스 객체의 변경이 프레젠테이션에 영향을 끼치지 않는다.
• 2. 서로의 역할에 따른 관심사의 분리를 수행할수 있다.
• 3. 높은 응집력

### 10.5.4 Types of Controller

• use Case Controller, Facade Controller

### 10.5.5 Keeping Track of Use Case State ( Use Case 상태 추척 )

• 일부 비즈니스 프로세스는 상태 의존적일 수 있다.
• 시스템의 순서가 꼬일 수 있다.
• 그렇기 때문에 actor request에 대한 상태를 알 수 있도록 추적하는 것이 중요하다.
• 파사드 패턴은 저수준 객체들을 깔끔하게 감싼 고수준 객체를 만들는 과정이다. 복잡한 클라이언트 인터페이스를 숨길 수 있다.
• 파사드 컨트롤러가 전체 시스템에 대한 actor request를 처리하는 책임이 있다. 파사드 컨트롤러는 적은 use case와 시스템이 확장되지 않을때 사용한다.

### 10.5.6 Bloated Controller ( 비대해진 컨트롤러 )

• 컨트롤러는 높은 응집력, 고나심사 분리, 변화를 위한 설계, 정보 은닉의 장ㅈ머을 가지지만, 제대로 사용하지 않으면 과도한 책임이 부과되어 컨트롤러가 비대해진다.

### 10.5.7 Comparing Differnet Designs

• 변화를 위한 설계
• 관심사의 분리
• 높은 응집력
• 낮은 커플링
• 정보 은닉
• 단순하게 유지하기

### 10.5.8 컨트롤러 패턴을 적용해야 할때

• use case senario를 작성할때
• 기존 시나리오를 수정할때
• 시나리오 테이블을 구성할때
• 설계 시퀀스 다이어그램을 작성할 때
• 설계 시퀀스 다이어그램을 수정하여 적용

### 10.5.9 컨트롤러 사용 지침

• [10.1 Use cas가 소수이고, 앞으로 확장될일이 없으면 퍼사드 컨트롤러를 사용한다.]
• [10.2 컨트롤러 overloading을 피해라 ]
• [10.3 컨트롤러, 비즈니스 객체 및 기타 리소스 관리 객체에 처리할 책임을 적절히 할당해라]