객체지향 프로그래밍 순서

1. 어떤 class가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라.
   • 클래스는 공통적인 상태와 행동을 공유하는 객체들을 추상화한 것
   • 클래스의 윤곽을 잡기 위해서는 어떤 객체들이 어떤 상태와 행동을 가지는지를 먼저 결정해야 함
2. 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다.
   • 객체는 홀로 존재하는 것이 아니다. (도움을 주거나 의존하면서 살아가는 협력적인 존재)
   • 객체들의 모양과 윤곽이 잡히면 공통된 특성과 상태를 가진 객체들을 타입으로 분류하고 이 타입을 기반으로 클래스를 구현하라
   • 훌륭한 협력 → 훌륭한 객체 → 훌륭한 클래스

• 객체 = 상태(state) + 행동(behavior)
• 접근 제어 (access control) - 외부에서 접근을 통제할 수 있는 매커니즘
  • 접근 수정자 (access modifier) - public, protected, private

프로그래머의 역할

• 클래스 작성자 (class creator) - 새로운 데이터 타입을 프로그램에 추가
  • 구현 은닉 (implementation hiding) - 클라이언트 프로그래머에게 필요한 부분만 공개하고 나머지는 숨겨야 함
• 클라이언트 프로그래머 (client programmer) - 클래스 작성자가 추가한 데이터 타입을 사용
  • 필요한 클래스들을 엮어서 애플리케이션을 빠르고 안정적으로 구축하는 것

협력

• 객체의 내부 상태는 외부에서 접근하지 못하도록 감춰야 한다. 대신 외부에 공개하는 퍼블릭 인터페이스를 통해 내부 상태에 접근할 수 있도록 허용한다. 객체는 다른 객체의 인터페이스에 공개된 행동을 수행하도록 요청 (request)할 수 있다. 요청을 받은 객체는 자율적인 방법에 따라 요청을 처리한 후 응답 (response)한다.

• 메서드 (method) - 수신된 메시지를 처리하기 위한 자신만의 방법. (메시지 ≠ 메서드 → 다형성 (polymorphism)이 발생됨)

• 다형성 (polymorphism) - 객체가 동일한 메시지를 전송해도 실제로 어떤 메서드가 실행될 것인지는 메시지를 수신하는 객체의 클래스가 무엇이냐에 따라 달라진다.

• TEMPLATE METHOD - 부모 클래스에 기본적인 알고리즘의 흐름을 구현하고 중간에 필요한 처리를 자식 클래스에게 위임하는 디자인 패턴.

• 설계가 유연해질수록 코드를 이해하고 디버깅하기는 점점 더 어려워진다. 반면 유연성을 억제하면 코드를 이해하고 디버깅하기는 쉬워지지만 재사용성과 확장 가능성은 낮아진다.

• 업캐스팅 (upcasting) - 자식클래스가 부모클래스를 대신하는 것