알아두면 좋은 IT 지식 9 - 디자인 패턴, 다이어그램, 객체 지향 설계 원칙

디자인 패턴

Visitor(방문자) 패턴 <행위 패턴>
각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성한다.
분리된 처리 기능은 각 클래스를 문을 똑똑 두드리며 수행한다.

 

Observer 패턴 <행위 패턴>
한 객체의 상태가 변경되면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달한다.
분산된 시스템끼리 이벤트 생성, 발행(Publish), 이를 수신(Subscribe) 해야 할 때 이용한다.

 

Bridge 패턴 <구조 패턴>
구현부에서 추상층을 분리, 서로가 독립적으로 확장한다. 기능과 구현을 두 개의 별도 클래스로 구현한다.

 

Factory Method 패턴 <생성 패턴>

객체를 생성하기 위한 인터페이스를 정의한다. 어떤 클래스가 인스턴스화 될 것인지는 서브클래스가 선택하며,  Virtual-Constructor패턴 이라고도 부른다.

 

<행위적 패턴(Behavioral Pattern)>
1. 책임 연쇄(Chain of Responsibility)
2. 커맨드 (Command)
3. 인터프리터(Interpreter)
4. 반복자(Iterator)
5. 중재자(Mediator)
6. 메멘토(Memento)
7. 옵서버(Observer)
8. 상태(State)
9. 전략(Strategy)
10. 템플릿 메서드(template Method)
11. 방문자(Visitor)

 

프로토타입(Prototype) 패턴은 생성 패턴(Creational Pattern)이다.

생성 패턴 : 추상 팩토리, 빌더, 팩토리 메서드, 프로토타입, 싱글톤

 

코드(Code)의 주요 기능
식별 기능 : 데이터 간의 성격에 따라 구분.
분류 기능 : 특정 기준이나 동일한 유형에 해당하는 데이터를 그룹화.
배열 기능 : 의미를 부여하여 나열.
표준화 기능 : 다양한 정보를 컴퓨터에 의해 처리하기 위해서는 단일한 형태의 표준화된 표현이 필요.

 

협약에 의한 설계(Design by Contract)

클래스에 대한 여러 가정을 공유하도록 명세한 것을 말합니다. 소프트웨어 컴포넌트에 대해 보다 정확한 인터페이스 명세를 위하여 선행조건, 결과 조건, 불변 조건을 나타내는 설계 방법.

협약에 의한 설계의 세 가지 타입
선행조건(precondition) : 오퍼레이션이 호출되기 이전에 참이 되어야 할 조건입니다.
결과 조건(postcondition) : 오퍼레이션이 수행된 이후 만족하여야 하는 조건입니다.
불변 조건(invariant) : 클래스 내부가 실행되는 동안 항상 만족하여야 하는 조건입니다. (예를 들어 리스트 안의 노드가 항상 내림차순으로 되어야 하는 것)

 

행위(Behavioral) 다이어그램 (동적)
1. 유스 케이스(UseCase) 다이어그램

요구분석, 사용자 관점. (시스템(범위), 액터, 유스 케이스, 관계)

2. 시퀀스(Sequence) 다이어그램

시스템, 객체 메시지 표현 –(액터, 객체, 생명선, 실행 상자, 메시지)

UML 시퀀스 다이어그램 구성 항목
액터(실행), 활성 객체(object), 라이프라인(생명선), 메시지, 실행 상자

3. 커뮤니케이션(Communication) 다이어그램 – 메시지 표현 + 객체 간의 연관

4. 상태(State) 다이어그램 – 변화 표현, 럼바우 동적 모델링!

5. 활동(Activity) 다이어그램 – 기능 수행, 로직, 조건 처리의 흐름을 순서에 따라..!

6. 상호작용 개요(Interaction Overview) 다이어그램

7. 타이밍(Timing) 다이어그램

 

구조적 다이어그램 (정적)

1. 클래스 다이어그램 : 클래스 사이 관계, 구조 파악 ( 클래스, 제약조건, 관계)

2. 객체 다이어그램 : 인스턴스, 럼바우가 객체 모델링에 활용

3. 컴포넌트 다이어그램 : 컴포넌트, 구현 단계

4. 배치 다이어그램 : 구현 단계, 노드와 의사소통, 컴포넌트 간 관계, 인터페이스

5. 복합체 구조 다이어그램 : 복합구조

6. 패키지 다이어그램 : 그룹화함

 

객체지향 설계 원칙
1. 단일 책임 원칙(SRP, Single Responsibility Principle)
객체는 단 하나의 책임만 가져야 한다.
2. 개방-폐쇄의 원칙(OCP, Open Closed Principle)
기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다.
3. 리스 코프 치환 원칙(LSP, Liskov Substitution Principle)
일반화 관계에 대한 이야기며, 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위 정도는 수행할 수 있어야 한다.
4. 인터페이스 분리 원칙(ISP, Interface Segregation Principle)
인터페이스를 클라이언트에 특화되도록 분리시키라는 설계 원칙입니다.
5. 의존 역전 원칙(DIP, Dependency Inversion Principle)
의존 관계를 맺을 때 변화하기 쉬운 것이나 자주 변화하는 것보다는 변화하기 어려운 것, 거의 변화가 없는 것에 의존하라는 것입니다.

 

소프트웨어 버전 등록 관련 주요 용어
- 저장소(Repository) : 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳입니다.
- 가져오기(Import) : 버전 관리가 되고 있지 않은 아무것도 없는 저장소에 처음으로 파일을 복사합니다.
- 체크아웃(Check-Out) : 프로그램을 수정하기 위해 저장소에서 파일들을 받아 옵니다. 소스 파일과 함께 버전 관리를 위한 파일들도 받습니다.
- 체크인(Check-In) : 체크아웃 한 파일의 수정을 다 하고 난 후 저장소의 파일을 새로운 버전으로 갱신합니다.
- 커밋(Commit) : 체크인을 수행할 때 전에 갱신된 내용이 있을 때, 충돌함을 알리고 diff 도구를 이용해 수정 후 갱신 완료.
- 동기화(Update) : 저장소에 있는 가장 최신의 버전으로 본인의 작업 공간을 동기화합니다.