1. 객체는 자신의 이름이 나태내는 일을 해야합니다.
   객체가 비행기라고 명명되면, 아마 이륙하고(takeOff()) 착륙해야(land()) 하지만 비행기표를 받지는 말아야 합니다. - 그 일(takeTicket())은 비행기의 일이 아닌 다른 객체의 일이어야 합니다.
   
2. 각 객체는 하나의 개념을 나타내어야 합니다.
   객체가 두 개 이상의 임무를 맡지 말아야 합니다 .오리 객체가 꽥꽥거리는 오리, 노란 플라스틱 장난감 오리, 오리 같이 행동하는 사람의 세 가지 개념을 나타내는 것은 피해야 합니다.
   
3. 사용되지 않는 속성이 결정적 증거입니다.
   객체가 값이 없거나 null인 속성들을 가진 채로 사용되면, 객체가 하나 이상의 일을 하고 있을 가능성이 있습니다. 어떤 속성에 값이 없는 경우가 대부분이라면, 그 속성이 왜 그 객체의 속성이어야 합니까? 그 속성들의 일부만을 사용하는 더 좋은 객체가 있지 않을까요?

중복 코드를 볼 때마다 캡슐화 할 곳이 있는지를 찾아보세요.

위임은 객체가 어떤 일을 할 때 직접 하지 않고 다른 객체가 그 일을(또는 일의 한 부분을) 하도록 하는 것을 말합니다.

위임: 한 객체가 오퍼레이션(기능)을 다른 객체에게 넘겨주어 첫 번재 객체를 대신해서 수행하도록 하는 행위

요구 사항 : 하나의 요구 사항은 특정 상품이나 서비스가 어떤 것이어야 하는지 또는 무엇을 수행해야 하는지를 자세하게 설명하는 것입니다. 주로 시스템 엔지니어링이나 소프트웨어 엔지니어링 분야에서 공식적으로 자주 사용합니다.

좋은 요구 사항을 얻는 가장 좋은 방법은 시스템이 무엇을 해야 하는지를 이해하는 것입니다.

유스케이스는 고객의 특정한 목표를 달성하기 위해 여러분의 시스템이 무엇을 하는지를 기술합니다.

하나의 유스케이스는 하나의 목표에만 집중합니다.

유스케이스 : 유스케이스는 새로 만들 시스템이나 소프트웨어 변경사항에 대한 요구 사항을 찾아내는 방법입니다. 각 유스케이스는 특정 목표를 달성하기 위해 시스템이 사용자 또는 다른 시스템과 어떻게 상호작용 하는지를 전달하는 하나 이상의 시나리오를 제공합니다.

좋은 유스케이스에는 기본적으로 세 가지 부분이 있고, 유스케이스가 일을 끝내려면, 모두 필요합니다.

1. 명확한 가치
   
   모든 유스케이스는 시스템에게 명확한 가치를 가지고 있어야 합니다. 유스케이스가 고객의 목표 달성에 도움이 되지 않는다면 소용없는 유스케이스입니다.
2. 시작과 종료
   
   모든 유스케이스는 명확한 시작 시점과 종료 시점이 있어야 합니다. 뭔가가 유스케이스를 기동시키고, 유스케이스가 완료되었음을 표시하는 상태가 있어야 합니다.
3. 외부 기동자 (액터)
   
   모든 유스케이스는 액터에 의해 시작됩니다. 액터는 주로 사람이지만 시스템 외부의 어떤 것이나 될 수 있습니다.

구현보다는 인터페이스에 의존하도록 코딩하는 것이 소프트웨어를 확장이 용이하게 합니다.

인터페이스는 여러 타입에 적용되는 행동을 정의하는 역할과 그 여러 타입을 사용하는 클래스들의 관심의 초점을 나타내는 역할의 두 가지 역할이 있습니다.

인터페이스에 의존하도록 코딩하면, 여러분의 코드는 인터페이스의 서브클래스 모두¹⁾와 잘 동작할 것입니다.

• 잘 디자인된 소프트웨어는 변경과 확장이 쉽다.
• 기본적인 캡슐화와 상속 같은 객체지향 원리를 사용하여 소프트웨어를 좀 더 유연하게 만드세요.
• 디자인이 유연하지 않으면, 변경하세요. 변경해야 하는 것이 여러분의 디자인이더라도, 결코 나쁜 디자인을 고수하지는 마세요.
• 여러분의 각 클래스의 응집도를 높게 하세요: 여러분의 클래스 각각은 하나의 일을 정말 잘하는 것에 중점을 두어야 합니다.
• 소프트웨어 디자인을 진행하면서, 항상 높은 응집도를 위해 노력하세요.

• 변하는 것을 캡슐화하라.
• 구현에 의존하기보다는 인터페이스에 의존하도록 코딩하라.
• 각 클래스는 변경 요인이 오직 하나이어야 한다.

객체들 사이에 변하는 속성들이 있을 때, map같은 콜렉션을 사용해서 속성들을 동적으로 저장하세요.

새로운 속성들이 여러분의 클래스에 추가되어도, 메소드들을 추가하거나 코드를 변경할 필요가 없습니다.

응집도 : 응집도는 하나의 모듈, 클래스, 또는 객체들을 이루는 원소들 사이에 연결의 정도를 나타냅니다. 여러분이 작성한 소프트웨어의 응집도가 높을수록, 여러분의 프로그램에서 각 클래스의 역할들이 잘 정의되어 있고 잘 연결되어 있는 것입니다. 각 클래스는 밀접하게 연결되어 있는 하나의 매우 특정한 집합의 일들을 수행합니다.

도메인 분석: 기존 시스템과 개발 이력, 도메인 전문가들로부터 얻은 지식, 기반 이론, 그리고 도메인에서 새로 등장하는 기술을 기반으로 도메인 관련 정보를 찾아내고, 모으고, 구조화하고, 나타내는 프로세스.

• 고객의 말에 귀 기울여, 여러분이 만들어 주길 바라는 것이 무엇인지 알아낸다.
• 특징 리스트를 고객이 이해하는 용어를 사용하여 작성한다.
• 작성한 특징 리스트가 고객이 실제로 원하는 것인지 확인한다.
• 유스케이스 다이어그램(과 유스케이스들)을 사용하여 시스테므이 청사진을 만든다.
• 디자인 패턴을 시스템의 작은 섹션에 적용한다.

아키텍처: 아키텍처는 시스템의 분할, 나뉜 부분들 사이의 연결과 상호 작용 메커니즘, 그리고 시스템의 디자인에 사용된 원리와 결정 사항들을 담고있는 시스템의 구조입니다.

자식 타입들은 부모 타입들이 사용되는 곳에 대체될 수 있어야 한다.

상속을 오용하는 코드들은 이해하기 어렵습니다.

위임(Delegation)은 특정 일의 책임을 다른 클래스나 메소드에 맡길 때를 지칭합니다.

다른 클래스의 기능을 사용해야 하지만 그 기능을 변경하고 싶지 않다면, 상속 대신 위임(Delegation)의 사용을 고려하세요.

구성(Composition)을 통해 하나의 인터페이스를 구현한 여러 클래스들의 기능을 사용할 수 있고 실행 중에 그 클래스를 바꾸어 기능을 변경할 수 있습니다.

구성(Composition)에서는, 다른 행동들로 구성된 객체는 그 행동을 소유하고 있는 것입니다. 그 객체가 없어지면, 소유하고 있던 모든 행동들도 없어집니다. 구성에 참여한 행동들은 그 구성의 외부에서는 존재하지 않습니다.

집합(Aggregation)은 한 클래스가 다른 클래스의 부분으로 사용되지만 다른 클래스의 외부에서도 여전히 존재하는 경우를 지칭합니다.

여러분은 여러분의 소프트웨어를 생각할 수 있는, 모든 가능한 사용 방법으로 테스트해야 합니다. 창조적이어야 합니다.

소프트웨어의 잘못된 사용 방법에 대해서도 테스트하는 것을 잊지 마세요. 여러분은 초기에 오류를 잡아낼 것이며, 여러분의 고객을 기쁘게 할 것입니다.

특징 리스트는 모두 소프트웨어가 무엇을 해야하는지 이해하는 것에 대한 것입니다.

유스케이스 다이어그램은 불필요한 세부 항목들 속으로 빠져들지 않고, 소프트웨어악 어떻게 사용될 것인지에 대해 생각할 수 있도록 합니다.