[오브젝트] 객체지향 프로그래밍

"오브젝트: 코드로 이해하는 객체지향 설계" 책의 기록입니다.

객체지향 설계

• 설계란 코드를 배치하는 것이다.
• 설계를 구현과 떨어트려서 이야기하는 것은 불가능하다.
• 좋은 설계란, 오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계
  • 왜? 요구사항이 항상 변경되기 때문임. 개발을 시작하는 시점에 구현에 필요한 모든 요구사항을 수집하는 것은 불가능에 가까움
  • 코드를 변경할 때 버그가 추가될 가능성이 높기 때문
• 변경에 유연하게 대응할 수 있는 코드를 짜자.ᐟ

객체지향 프로그래밍을 향해

다음 두 가지에 집중하자

• 첫째, 어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라. 클래스의 윤곽을 잡기 위해서는 어떤 객체들이 어떤 상태와 행동을 가지는지 먼저 결정
• 둘째, 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다. 이것은 설계를 유연하고 확장 가능하게 만듬

도메인

• 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야
• 도메인을 구성하는 개념들이 프로그램의 객체와 클래스로 매끄럽게 연결

[그림] 영화 예매 도메인을 구성하는 타입들의 구조

클래스 구현하기

• 훌륭한 클래스를 설계하기 위한 핵심은 어떤 부분을 공개하고 어떤 부분을 감출지를 결정하는 것
  • 왜? 경계의 명확성이 객체의 자율성을 보장하기 때문

프로그래머의 자유

• 프로그래머의 역할을 클래스 작성자, 클라이언트 프로그래머로 구분하는 것이 유용
  • 클래스 작성자 : 클라이언트 프로그래머에게 필요한 부분만 공개하고 나머지는 꽁꽁 숨겨야함 → 구현은닉
  • 클라이언트 프로그래머 : 필요한 클래스들을 엮어 애플리케이션을 빠르고 안정적으로 구축하는 것이 목표
• 클라이언트 프로그래머가 private 속성이나 메서드에 접근하려고 시도하면 컴파일러는 오류를 뱉어낼 것
• 객체의 외부와 내부를 구분하면 클라리언트 프로그래머가 알아야 할 지식의 양은 줄어들고, 클래스 작성자가 자유롭게 구현을 변경할 수 있는 폭은 넓어짐

협력하는 객체들의 공동체

• 금액이라는 개념을 구현하기 위해 Long 타입을 사용할 수 있음
• 그러나, Long 타입은 저장하는 값이 금액과 관련되어 있다는 의미를 전달할 수 없음
• 의미를 좀 더 명확하게 표현할 수 있다면 Money 객체를 사용하여 해당 개념을 구현하라
  • 비록 하나의 인스턴스 변수만 포함하더라도 개념을 명시적으로 표현하는 것은 전체적인 설계의 명확성과 유연성을 높임

오버라이딩과 오버로딩

• 오버라이딩 : 부모 클래스에 정의된 같은 이름, 같은 파라미터 목록을 가진 메서드를 자식 클래스에서 재정의하는 경우. 외부에서는 부모 클래스의 메서드가 보이지 않음
• 오버로딩 : 메서드의 이름은 같지만 제공되는 파라미터의 목록이 다름. 해당 메서드들은 사이 좋게 공존

컴파일 시간 의존성과 실행 시간 의존성

• 어떤 클래스가 다른 클래스에 접근할 수 있는 경로를 가지거나, 해당 클래스의 객체의 메서드를 호출할 경우 두 클래스 사이에 의존성이 존재한다고 말함
• 코드의 의존성과 실행 시점의 의존성은 서로 다를 수 있음
• 의존성이 다르면 다를수록 코드를 이해하기 어려움, 그러나 더 유연해지고 확장 가능해짐 → 트레이드오프

상속

• 객체지향에서 코드를 재사용하기 위해 가장 널리 사용되는 방법
• 차이에 의한 프로그래밍 (programming by difference)
• 업캐스팅 : 자식 클래스가 부모 클래스를 대신하는 것

다형성

• 객체지향 프로그램의 컴파일 시간 의존성과 실행 시간 의존성이 다를 수 있다는 사실을 기반
• 동일한 메시지를 수신했을 때 객체의 타입에 따라 다르게 응답하는 능력
• 인터페이스를 통일하기 위해 사용한 방법 → 상속
  • 상속으로 동일한 인터페이스를 고유하는 클래스들을 하나의 타입 계층으로 묶을 수 있음

추상화

• 추상화의 계층만 따로 떼어 놓고 살펴보면 요구사항의 정책을 높은 수준에서 서술 가능
• 추상화를 이용하면 설계가 좀 더 유연해짐