1. 객체, 설계

• 프로그래밍 패러다임의 유용성
  • 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유
    • 불필요한 충돌 방지
    • 동일한 규칙과 방법을 공유하는 개발자로 성장

 

소프트웨어 모듈의 세가지 목적 - by,. 로버트 마틴(Robert C. Martin)

1. 실행 중에 제대로 동작
2. 변경을 위해 존재
3. 코드를 읽는 사람과 의사소통

모듈이란 크기와 상관 없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소 - p.14

• 이해가 가능한 코드
  • 우리의 예상에서 크게 벗어나지 않는 코드
  • 기억할 내용이 적은 코드
• 변경이 용이한 코드 
  • 의존성이 적은 코드
    • 협력을 위한 최소한의 의존성만 유지하고 불필요한 부분은 제거
    • 두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 어려워진다. 

변경이 용이하게 코드를 만드는 방법, 캡슐화

• 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것
• 객체 내부로의 접근을 제한하면 객체 사이의 결합도를 낮추어 설계를 더욱 쉽게 변경 가능
• 인터페이스와 구현을 분리하여 달성 가능

프로세스와 데이터

• 프로세스: Theater의 enter 메서드
• 데이터: Audience, TicketSeller, Bag, TicketOffice
• 프로세스와 데이터를 같은 모듈에 위치 시키는 것은 객체 지향적인 특성
• 프로세스와 데이터를 다른 모듈에 위치 시키는 것은 절차 지향적인 특성
• 책임의 관점에서 보자면, 절차지향에서는 Theater가 설계의 전체적인 작업을 도맡아 처리한다면, 객체지향 설계에서는 각 객체가 자신이 맡은 일을 처리했다. 이를 '책임의 이동'이라고 한다.
• 객체지향 설계의 핵심은 적절한 객체에 적절한 책임을 할당하는 것

의인화

비록 현실에서는 수동적인 존재라고 하더라도 일단 객체지향의 세계에 들어오면 모든것이 능동적이고 자율적인 존재로 바뀐다.
능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 의인화라고 부른다. - P.33

예: Bag, TicketOffice 등은 현실에선 수동적이지만 객체지향에선 자신 스스로의 책임을 진다.

설계란?

• 설계는 코드를 작성하는 매 순간 코드를 어떻게 배치할 것인지 결정하는 과정
• 설계는 코드 작성의 일부이며 코드를 작성해야만 검증 가능

좋은 (객체지향) 설계란?

• 기능을 구현
• 쉽게 변경 가능한 코드
• 협럭하는 객체 사이의 의존성을 적절히 관리하는 설계
• 데이터와 프로세스를 하나의 덩어리로 모으는 설계