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

도메인 구조를 따르는 프로그램 구조

도메인이란?

문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야

• 도메인 개념을 구현하기 위해서는 클래스를 사용함

→ 클래스 이름은 대응되는 도메인 개념의 이름과 동일하거나 유사하게 지어야한다. 왜? 클래스 사이의 관계도 최대한 도메인 개념 사이에 맺어진 관계랑 유사하게 만들어서 프로그램의 구조를 이해하고 예상하기 쉽게 만들어야하기 때문!

 

클래스 구현

public class Screening {
	private Movie movie;
	private LocalDateTime whenScreened;
	
	public Screening(Movie movie, LocalDateTime whenScreened) {
		this.movie = movie;	
		this.whenScreened = whenSceened;
	}
	
	public LocalDateTime getStartTime() {
		return whenScreened;
	}
...
}

인스턴스 변수의 가시성은 private이고, 메서드는 public이다.

 

여기서 가시성이란?

public, private, protected 같은 공개범위를 뜻한다.

 

✍️ 클래스의 경계를 구분짓자

클래스는 내부와 외부로 구분되며, 훌륭한 클래스를 설계하기 위해서는 핵심 부분을 외부에 공개하고, 어떤 부분을 감출지 정해야 한다!!

→ 외부에서는 개체의 속성에 직접 접근할 수 없도록 막고 적절한 public 메서드를 통해서만 내부 상태를 변경해야 한다.

→ 왜? 경계의 명확성이 객체의 자율성을 보장하기 때문이다.

 

그럼 객체의 자율성을 어떻게 보장할까?

• 캡슐화
  • 데이터의 기능을 객체 내부로 함께 묶음
• 접근 제어
  • 외부에서 접근을 통제함
• 접근 수정자
  • 접근 제어를 위해 public, protected, private를 사용

캡슐화와 접근 제어는 객체를 두 부분으로 나눈다.

1. 퍼블릭 인터페이스
2. 외부에서 접근 가능한 부분
3. 구현
4. 외부에서는 접근 불가능하고 오직 내부에서만 접근 가능한 부분

👉 객체의 상태는 숨기고 행동만 외부에 공개하자!!

 

 

구현 은닉을 구현하자

프로그래머의 역할을 클래스 작성자, 클라이언트 프로그래머로 구분하자 클라이언트 프로그래머가 숨겨 놓은 부분에 마음대로 접근할 수 없도록 방지하여서 클라이언트 프로그래머에 대한 영향을 걱정하지 않고도 내부 구현을 마음대로 변경할 수 있어야 한다.

 

협력하는 객체들의 공동체

public class Money {
	public static final Money ZERO = Money.wons(0);
	
	private final BigDecial amount;
	
	public static Money wons(long amount) {
		return new Money(BigDecimal,valueOf(amount));
	}
}

public class Reservation {
	private Money fee;
	
	public Reservation (Money fee) {
		this.fee = fee;
	}
}

요금을 long 타입을 사용하는 것이 아니라 객체를 사용했다.

이렇게 객체로 나타내면 하나의 인스턴스 변수만 포함하더라도 개념을 면시적으로 표현하는 것만으로도 전체적인 설계의 명확성과 유연성이 높아진다.

 

상속과 다형성

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

→ 항상 유연성과 가독성 사이에서 고민하자. 무조건 유연한 설계도 읽기 쉬운 코드도 정답이 아닌 것을 기억하자

 

차이에 의한 프로그래밍이란?

부모 클래스와 다른 부분만 추가해서 새로운 클래스를 쉽고 빠르게 만드는 방법

 

업캐스팅이란?

자식 클래스가 부모 클래스를 대신하는 것

 

다형성이란?

동일한 메시지를 수신했을 때 객체 타입에 따라 다르게 응답할 수 있는 능력

 

책에서는 프로그램을 작성할 때 Movie클래스가 추상클래스인 DiscountPolicy에 의존한다. 컴파일 시간 의존성은 Movie에서 DiscountPolicy로 향한다.

반면, 실행 시점에는 실제 상호작용하는 AmountDiscountPolicy, PercentDiscountPolicy 인스턴스이다.

다형성을 이용해서 객체들은 모두 같은 메시지를 이해할 수 있어야 한다. AmountDiscountPolicy, PercentDiscountPolicy는 DiscountPolicy를 상속받았기 때문에 다형적인 협력에 참여할 수 있던 것이다.

 

다형성을 구현하는 방법?

• 지연 바인딩 또는 동적 바인딩
  • 메시지와 메서드를 실행 시점에 바인딩하는 것
• 초기 바인딩 또는 정적 바인딩
  • 전통적인 함수 호출처럼 컴파일 시점에 실행될 함수나 프로시저를 결정하는 것

상속이란?

객체지향에서 코드를 재사용하기 위해 널리 사용되는 기법이다.

 

상속의 단점

• 캡슐화를 위반한다.
  • 상속을 하기 위해서는 부모 클래스의 내부 구조를 잘 알고 있어야 한다. 결과적으로 부모 클래스의 구현이 자식 클래스에게 노출되기 때문에 캡슐화가 약해진다.
• 설계가 유연하지 않다.
  • 부모 클래스와 자식 클래스 사이의 관계를 컴파일 시점에 결정한다. → 실행 시점에 객체의 종류를 변경하는 것이 불가능하다.

이 단점을 극복하기 위해 나타난 개념이 합성이다.

 

합성이란?

인터페이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법

• 인터페이스에 정의된 메시지를 통해서만 재사용이 가능하기 때문에 구현을 효과적으로 캡슐화할 수 있다.
• 의존하는 인스턴스를 교체하는 것이 비교적 쉽기 때문에 설계를 유연하게 만든다.

→ 상속은 클래스를 통해 강하게 결합되는 데 비해 합성은 메시지를 통해 느슨하게 결합된다. 따라서 코드의 재사용이 훨씬 좋아진다.

하지만, 상속을 지양하지 말라는건 아님!! 합성과 상속을 함께 사용하자