Post

OOP 활용하기

OOP 활용하기

Readable Code: 읽기 좋은 코드를 작성하는 사고법를 듣고 요약한 내용입니다.

상속과 조합

  • 상속보다 조합을 사용하자!
  • 상속은 시멘트처럼 굳어지는 구조다. 수정이 어렵다.

    → 부모와 자식의 결합도가 높다.

  • 조합과 인터페이스를 활용하는 것이 유연한 구조.

    → 중복이더라도 유연한 구조 »» 상속을 통한 코드의 중복 제거

Value Object

  • 도메인의 어떤 개념을 추상화하여 표현한 값 객체
  • 값으로 취급하기 위해서, 불변성, 동등성, 유효성 검증 등을 보장해야 한다.
    • 불변성
      • final 필드, setter 금지
    • 동등성
      • 서로 다른 인스턴스여도(동일성이 달라도), 내부 값이 같으면 같은 값으로 취급한다.
      • equals() & hashCode() 재정의 필요
    • 유효성 검증
      • 객체가 생성되는 시점에 값에 대한 유효성을 보장하기
1
2
3
4
5
6
7
8
9
10
11
12
13
public class Money {
	
		private final long value; // 불변성
		
		public Money(long value) {
				if (value < 0) { // 유효성 검증
						throw new IllegalArgumentException("돈은 0원 이상이어야 합니다.");
				}
				this.value = value;		
		}

		// equals() & hashCode() 재정의 // 동등성
}
1
2
3
4
5
Money money1 = new Money(1_000L);
Money money2 = new Money(1_000L);

assertThat(money1 == money2).isFalse();
assertThat(money1.equals(money2)).isTrue();

VO vs Entity

Entity는 식별자가 존재한다. 식별자가 아닌 필드의 값이 달라도, 식별자가 같으면 동등한 객체로 취급한다.

  • equals() & hashCode()도 식별자 필드만 가지고 재정의할 수 있다.
  • 식별자가 같은데 식별자가 아닌 필드의 값이 서로 다른 두 인스턴스가 있다면, 같은 Entity가 시간이 지남에 따라 변화한 것으로 이해할 수 있다.

VO는 식별자가 없이, 내부 모든 값이 다 같아야 동등한 객체로 취급한다.

  • 개념적으로, 전체 필드가 다같이 식별자 역할을 한다고 생각해도 된다.

일급 컬렉션

  • 다른 요소에게 사용 가능한 모든 연산을 지원하는 요소
    • 변수로 할당될 수 있다.
    • 파라미터로 전달될 수 있다.
    • 함수의 결과로 반환될 수 있다.
  • 컬렉션을 포장하면서, 컬렉션만을 유일하게 필드로 가지는 객체
    • 컬렉션을 다른 객체와 동등한 레벨로 다루기 위함
    • 단 하나의 컬렉션 필드만을 가진다.
  • 컬렉션을 추상화하며 의미를 담을 수 있고, 가공 로직의 보금자리가 생긴다.
    • 가공 로직에 대한 테스트도 작성할 수 있다.
  • 만약 getter로 컬렉션을 반환할 일이 생긴다면?
    • 외부 조작을 피하기 위해 새로운 컬렉션으로 반환해야함.

Enum

  • 상수의 집합
    • 상수와 관련된 로직을 담을 수 있는 공간
    • 상태와 행위를 한 곳에서 관리할 수 있는 추상화된 객체
  • 특정 도메인 개념에 대해 그 종류와 기능을 명시적으로 표현해줄 수 있다.
  • 만약 변경이 잦은 개념이라면, DB로 관리하는 것이 낫다.

다형성 활용하기

어떤 조건을 만족하면, 그 조건에 해당하는 행위를 수행한다.

→ 변화하는 것

  • 조건 & 행위

→ 변화하지 않는 것

  • 조건을 만족하는지 체크
  • 행위를 수행

숨겨져 있는 도메인 개념 도출하기

  • 도메인 지식은 만드는 것이 아니라 발견하는 것
  • 객체 지향은 현실을 100% 반영하는 것이 아니라, 흉내내는 것

    → 현실 세계에서도 쉽게 인지하지 못하는 개념도 도출하여 사용해야 한다.

  • 설계할 때는 근시적, 거시적 관점에서 최대한 미래를 예측해야함.
    • 주의! 과도하게 예측할 경우 오버엔지니어링이 될 수 있음.
  • 시간이 지난 시점에서 틀렸다는 것을 인지하면, 돌아올 수 있어야 한다.

💡 레거시를 보았을 때, “왜 이따구로 짰지?” 라는 생각이 들 때가 있다.

그러나 완벽한 설계는 없다. 그 당시에는 그게 최선이었다

This post is licensed under CC BY 4.0 by the author.