DesignPrinciples

UserPreferences

1 개요

코드 디자인과 관련된 내용들.

2 Responsibility-Driven Design

from Object Design

ROLES, RESONSIBILITIES, AND COLLABORATIONS



2.1 역할(Role)의 종류

Information holder	정보를 알고 이를 제공한다.
Structurer	오브젝트 간의 관계 및 그 관계에 대한 정보를 유지한다.
Service provider	실제 일(일반적으로 계산과 관련된 일)을 수행한다.
Coordinator	다른 오브젝트들에게 일을 위임함으로서 이벤트에 반응한다.
Controller	의사 결정을 하고, 다른 오브젝트들의 행동을 제어한다.
Interfacer	시스템 여러 부분에서의 정보 및 요청들을 가공한다.




2.2 클래스 찾기

구현하고자하는 애플리케이션의 여러 가지 특징들을 정해서 이를 테마로 정한다. 그리고 그 테마 안에서 다음과 같은 것들을 찾아본다.


• 시스템이 하는 일 (The work your system performs)
  
• 시스템이 영향을 미치는 것들 또는 시스템에 직접적으로 연결되어있는 것들 (Things directly affected by or connected to the application (other software, physical machinery, hardware devices) )
  
• 시스템을 관통하며 흐르는 정보들 (Information that flows through your software)
  
• 의사 결정, 컨트롤, 조율 (Decision making, control, and coordination activities)
  
• 오브젝트의 구조 및 그룹 (Structures and groups of objects)
  
• 애플리케이션이 알아야 하는 현실에서의 어떤 것에 대한 표현 (Representations of real-world things the application needs to know something about)
  
  
  

3 링크

• Object Oriented Design Tips
  
오브젝트들을 디자인할 때 고려할 사항

• Object Oriented Design Tips II
  
오브젝트들을 디자인할 때 고려할 사항

• Keep It Simple
  
완벽한(perfect) 디자인은 좋은(good) 디자인의 적이다.

• Open Closed Principle
  
클래스, 모듈, 함수와 같은 소프트웨어 엔티티는 확장에는 열려 있어야 하나, 수정에는 닫혀 있어야 한다.

• Liskov Substitution Principle
  
클래스 계층도에서, 특화된 오브젝트를 베이스 클래스 오브젝트로 취급하는 것이 가능해야한다.

• Dependency Inversion Principle
  
하이 레벨의 모듈은 로우 레벨의 모듈과 직접적인 의존 관계를 가지면 안 된다. 둘 모두 추상화를 통해 의존 관계를 가져야한다. 추상화는 실제 구현과는 분리되어야하고, 실제 구현 또한 추상화와는 분리되어야 한다.

• Design by Contract in C++
  
Eiffel 언어에서 따온 contract라는 개념을 Cpp에다 적용시키기

• Desiging Datastructures for Longevity
  
C/C++ 구조체를 버전 올려가며 이전 버전과 호환성 유지하기. 라이브러리를 제작하는 사람이라면 한번쯤 생각해볼 사항.

• CategoryDesign