- AKA: Also Known As
- 응집력 있는 책임들: 관심(책임)분리 원칙에 맞춰 유지
- UI는 이벤트 핸들러 정도만 구현, 총액 계산은 구현하지 않음
- 관심 분리와 높은 응집도 유지
- 모델 뷰 분리 원칙 (model-view separation)
UI는 계속 변하지만 Domain은 주로 유지됨.
따라서 UI(View), Domain(Model)을 분리해야 편함.
코드
- 소스코드 구조를 계층과 UML 패키지로 매칭
- 객체지향 언어는 대개 패키지를 지원
//UI 계층
com.mycompany.nextgen.ui.swing
com.mycompany.nextgen.ui.web
//DOMAIN 계층
//packages specific to the NextGen project
com.mycompany.nextgen.domain.sales
com.mycompany.nextgen.domain.payments
//TECHNICAL SERVICES 계층
//our home-grown persistence (DB) access layer
com.myhomepany.service.persistence
//Third party
org.apache.log4j
org.apache.soap.rpc
//FOUNDATION 계층
//foundation packages that our tham creates
com.mycompany.util
도메인 객체, 어플리케이션 로직
-
객체를 이용해 어떻게 어플리케이션 로직을 설계할 것인가?
- 경우1: 클래스를 하나 만들어 모든 일을 수행하게 함- 경우2: 도메인에서 사용되는 개념들을 만들어 업무를 나우어서 수행 -> 도메인 객체
- 예. Sale -> 합계를 계산하게 함
- 경우2: 도메인에서 사용되는 개념들을 만들어 업무를 나우어서 수행 -> 도메인 객체
-
어플리케이션 로직 계층을 도메인 객체라고 부름
모델 뷰 분리 원칙
- UI 객체 메서드에 응용 프로그램 로직을 넣지 마라
- 세금 계산과 같은
- UI 객체는 UI 요소만 초기화하고 UI 이벤트를 수신해야 함
- UI 객체가 아닌 것에 대한 응용 프로그램 로직에 대한 요청을 위임함
- UI가 아닌 객체를 UI 객체에 직접 연결하지 마라
- 예를 들어 윈도우가 아닌 객체는 새 어플리케이션에서 재사용되거나 새 인터페이스에 첨부될 수 있기 때문에 Sale S/W객체(도메인 객체)가 java swing jfram창 객체에 대한 참조를 갖도록 하지 마라
객체 설계로의 전이
Agile 모델링과 간단하게 UML 그리기
- Agile: 예민한, 민첩한 -> 상황에 맞춰 민감하게
- 목적: 문서 작성의 오버헤드를 줄이고 문서화가 아닌 의사소통을 위해 모델링
- 구성요소
- 다른 사람들과 함께 모델링
- 여러 모델을 병렬로 작성
계획 - 분석 - 설계 : upperCase
코딩 - 테스트 : lowCase
-> Integrated case (통합 케이스)
UML Case 도구
- computer-Aided Software Engineering Tool
- 순공학과 역공학
- 순공학: 계획, 분석, 개발, 테스트, 운영
- 역공학: 순공학의 반대로
코딩 전에 UML을 그리는 데 소요되는 적절한 시간은?
- 몇 시간에서 하루 정도
-
기본 설계
- 분량이 매우 적음
- 변경가능성이 적음
-
상세 설계
- 분량이 매우 많음
- 변경 가능성이 높음
- 따라서 완벽하게 작성하기 매우 힘들다
-
상세 설계는 필요한 만큼 필요한 때에 수행
- 계속 늘어나는 필요한 시간은 역공학으로 대체할 것
객체 설계: 정적 모델링과 동적 모델링의 차이
- 동적 vs 정적 -> 후행을 시키냐 안 시키냐의 차이
- 동적 모델: Interaction Diagram
- 로직, 코드의 행위, 메소드의 바디를 설계
- 시퀀스 다이어그램과 커뮤니케이션 다이어그램
- 정적 다이어그램
- 패키지, 클래스 이름, 속성, 메소드의 시그니처
- 정적: static model -> UML Class Diagram
- 동적: dynamic model -> UML Sequence Diagram
동적 객체 모델링
- Interation Diagram
- 모델링 하는 동안 Reponsibility-driven Design 및 GRASP 원칙 적용
- 동적 모델링에서 그 밖에 State Machine Diagram과 Activity Diagram을 적용할 수도 있음
정적 객체 모델링
- 동적 객체 모델링과 병행해 작업
- Package Diagram(논리)과 Deployment Diagram(물리)을 사용함
- 배치도, 설치도
- 논리적 구조/물리적 구조
CRC (Class - Reponsibility - Collaborator)
- UML 표기 기술과 비교한 객체 설계 기술의 중요성
- CRC 방식을 지금은 사용하지 않지만 이 개념이 UP와 Design Pattern에 녹아 들어감
객체는 많을수록 좋음
많으면 잘게 쪼갤 수 있으니까
UML Interaction Diagram
Sequence Diagram과 Communication Diagram
-
2개 중 상황에 맞춰서 선택해 사용하면 됨
-
Sequence Diragram
-
Communication Diagram
class A {
B myB = new B();
doOne {
myB.doTwo();
myB.doThree();
}
}
class B {
doTwo();
doThree();
}Sequence Diagram과 Communication Diagram의 장단점
Sequence Diagram 예제: makePayment
- makePayment 메시지는 Register의 인스턴스로 전달됨
- Register 인스턴스는 Sale 인스턴스로 makePayment 메시지를 전달함
- Sale 인스턴스는 Payment 인스턴스를 만듦
UML Interaction Diagram의 표기법
CLASS vs OBJECT ?
- Object: 클래스
- class: 오브젝트
-> 첫 글자 대문자로 시작하면 클래스 아니면 오브젝트
<<metaclass>>: 스테레오 타입 -> 클래스임을 나타앰- 보통 기울임꼴을 사용하면 class
x: List:<<interface>>
Singleton 객체의 표현
- 전역 변수가 사용하고 싶을 때는?
- 전역 변수(C, C++)
- 정적 변수(C++, Java)
- Singleton
Singleton 이란?
- Singleton 패턴의 용도는 하나의 프로그램 내에서 하나의 인스턴스만을 생성해야만 하는 상황
- 예를 들어 환경설정을 관리하는 클래스나 Connection Pool, Thread Pool과 같이 풀(Pool) 형태로 관리되는 클래스의 경우 프로그램 내에서 단 하나의 인스턴스로 관리되는 것이 일반적, 이때 싱글톤 패턴을 적용
