섹션5. 객체 지향 적용하기

1. 상속과 조합

📌 상속보다 조합을 사용하자!

• 상속은 시멘트처럼 굳어지는 구조로 수정이 어렵다.
  • 부모와 자식의 결합도가 높다. → 부모의 기능을 자식이 그대로 가져가서 사용하기 때문
  • 자식이 부모의 모든 행위와 기능을 알고 있어야한다. → 캡슐화가 깨지는 것
  • 부모의 행위와 기능이 조금이라도 변경되면 모든 자식들이 다 영향을 받는다.
• 조합과 인터페이스를 활용하는 것이 유연한 구조
  • 상속을 통한 코드의 중복 제거가 주는 이점보다 중복이 생기더라도 유연한 구조 설계가 주는 이점이 더 크다.
  • 과거엔 하드웨어의 성능이 따라와주지 않으니 코드의 중복 제거를 통해 효율을 얻는 것이 효과적인 형태였으나 현재는 하드웨어 성능이 뛰어나기 때문에 조합이나 인터페이스를 활용하여 유지보수하기 쉬운 유연한 코드를 작성하는게 좋다.
• 상속구조를 사용해야만 효율적인 구조는 상속을 사용하고, 웬만하면 조합과 인터페이스 구조로 유연하게 풀어내자.

2. Value Object (VO)

• 기본타입을 객체로 감싸서 의미를 부여하고 추상화하는 기법
• 도메인의 어떤 개념을 추상화하여 표현한 값 객체
• 객체를 값으로 취급하기 위해 불변성, 동등성, 유효성 검증 등을 보장해야한다.
  • 불변성 : final 필드, setter 사용 금지
  • 동등성 : 서로 다른 인스턴스여도(동일성이 달라도), 내부의 값이 같으면 같은 값 객체로 취급한다.
    → equals() & hashCode() 재정의 필요
  • 유효성 검증 : 객체가 생성되는 시점에 값에 대한 유효성을 보장
    → 생성자에서 검증로직을 추가

Entity와 VO 차이

▼ Entity

class UserAccount {
	private String userId; // 식별자!!!
    private String 이름;
    private String 생년월일;
    private Address 집주소;
}

 

▼ VO

class Address {
	private String 시도;
    private String 시군구;
    private String 도로명;
    private String 건물번호;
}

• 제일 큰 차이점은 식별자이다.
  • Entity에는 식별자가 존재한다.
    • 식별자가 아닌 다른 필드의 값이 달라도, 식별자가 같으면 동등한 객체로 취급한다.
  • equals() & hashCode()도 식별자 필드만 가지고 재정의할 수 있음
    • 식별자가 같은데 식별자가 아닌 필듸의 값이 서로 다른 두 인스턴스가 있다면, 같은 Entity가 시간이 지남에 따라 변화한 것으로 이해할 수 있음
      • ex) userId가 동일한 상태에 휴대폰번호가 변경되어 phonNumber 필드가 수정됐다고 했을 때, 다른 객체로 보는 것이 아니라 식별자가 동일하니 동일한 객체로 본다.
  • VO는 식별자가 없다.
    • 내부의 모든 값이 다 같아야 동등한 객체로 취급된다.
    • 개념적으로 전체 필드가 다 같이 식별자 역할을 한다고 볼 수 있다.

3. 일급 컬렉션

일급 시민

• 다른 요소에게 사용 가능한 모든 연산을 지원하는 요소
  • 사용가능한 모든 연산이란? 아래와 같은 경우를 일급 시민이라고 불린다.
    • 어떤 요소가 변수로 할당 되거나
    • 어떤 요소가 파라미터로 전달되거나
    • 어떤 요소가 함수의 결과로 반환되거나
  • ex) 일급 함수
    • 함수형 프로그래밍 언어에서 함수는 일급 시민이라고 볼 수 있다.
      함수는 변수에 할당될 수 있고, 인자로 전달될 수 있고, 함수의 결과로 함수가 반환될 수 있다.

일급 컬렉션

• 컬렉션(List, Set, Map)을 포장하면서 컬렉션만을 유일하게 필드로 가지는 객체를 말한다.
  
  • 단 하나의 컬렉션 필드만 가진다.
• 컬렉션을 다른 객체와 동등한 레벨로 다르기 위해 사용된다.
• 컬렉션을 감싸면서 추상화하여 의미를 담을 수 있고, 가공 로직의 보금자리가 생긴다.
  • 가공 로직에 대한 테스트도 작성할 수 있게된다.
    → 컬렉션 자체만 코드 내에 돌아다니면 의미를 담을 수도 테스트를 할 수도 없는 코드가 된다.
    이를 VO처럼 한번 감싸서 가공 로직처럼 로직에 담는 것이다.
• 사용 주의 사항!
  • 만약 getter로 컬렉션을 반환할 일이 생기면 외부 조작을 피하기 위해 꼭 새로운 컬렉션을 생성하여 반환해야한다.
    → 외부에서 getter로 컬렉션을 변경할 수 있다면 정보의 일관성이 깨지기 때문(같은 메모리 주소를 공유하기 때문)

public List<CellPosition> getPositions() {
	return new ArrayList<>(positions);
}

4. Enum의 활용

• 상수의 집합으로 상수와 관련된 로직을 담을 수 있는 공간이다.
  
  • 상태와 행위를 한 곳에서 관리할 수 있는 추상화된 객체
• 특정 도메인 개념에 대해 그 종류와 기능을 명시적으로 표현해줄 수 있다.
  • ex) 레인보우 컬러 Enum 클래스라면? 빨,주,노,초,파,남,보를 상수로 정의할 수 있다.
• Enum의 상수 값이나 타입의 변경이 잦은 경우 Enum 보단 DB로 관리하는게 더 쉬울수도 있음

5. 다형성 활용하기

• 반복적인 if문을 단순하게 만들어볼 순 없을까?

private String decideCellSignFrom(CellSnapshot snapshot) {
    CellSnapshotStatus status = snapshot.getStatus();
    if (status == CellSnapshotStatus.EMPTY) {
        return EMPTY_SIGN;
    }
    if (status == CellSnapshotStatus.FLAG) {
        return FLAG_SIGN;
    }
    if (status == CellSnapshotStatus.LAND_MINE) {
        return LAND_MINE_SIGN;
    }
    if (status == CellSnapshotStatus.NUMBER) {
        return String.valueOf(snapshot.getNearbyLandMineCount());
    }
    if (status == CellSnapshotStatus.UNCHECKED) {
        return UNCHECKED_SIGN;
    }

    throw new IllegalStateException("확인할 수 없는 셀입니다.");
}

• 어떤 조건을 만족하면 그 조건에 해당하는 행위를 수행한다! → 이 기능을 if문을 통해 반복적으로 사용하고 있다.
• 구체와 추상을 통해 다형성을 활용할 수 있다.
• 변화하는 것 ↔ 변하지 않는 것
  • 조건 & 행위 ↔ 조건을 만족하는가?, 행위를 수행한다.
  • 변화하는 것은 유동적으로 해결해주어야하고, 변하지 않는 것은 지켜야 OCP를 지키는 구조가됨
  • 변하지 않는 것을 인터페이스화하고, 변하는 것을 구체클래스로 생성하여 다형성을 활용한다.
  • Enum을 활용할 수도있다.

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

• 도메인 지식은 만드는 것이 아니라 발견하는 것이다.
• 객체 지향은 현실을 100% 반영하는 도구가 아닌 흉내내는 것으로 현실 세계에서 쉽게 인지하지 못하는 개념도 도출해서 사용해야 할 때가 있다.
• 설계 할 떄는 근시적, 거시적 관점에서 최대한 미래를 예측하고, 시간이 지나 만약 틀렸다는 것을 인지하면 언제든 돌아올 수 있도록 코드를 작성해야한다.

📌 완벽한 설계는 없다. 그 당시의 최선이 있을 뿐

---

출처 : 인프런, 워밍업클럽3기 - 백엔드 코드
📎 Readable Code: 읽기 좋은 코드를 작성하는 사고법
📎 Practical Testing: 실용적인 테스트 가이드