공부한 것을 모아모아 :)

1. 도메인 검증은 도메인 객체에서~

항상 검증 로직의 위치가 애매했는데, 리뷰어 핀과 얘기하면서 내 코드는 OOP부터가 잘못됐다는 것을,, 깨달았다.

나 : 하나의 입력에서 검증 해야 하는 것들을 하나의 클래스에서 처리 하는 것이 검증 또한 하나의 책임이라고 생각했다.

핀 : 자동차 이름 정책이 변경된다면 검증 클래스와 도메인 모두 변경해야하므로 SRP를 지키지 못한다.

또한 도메인 검증을 도메인 객체에서 하는 것이 도메인 정책을 한 눈에 파악하기에 더 좋을 것 같다.

2. 유효성 검증을 위한 VO 도입

객체 내에서 필드 값의 유효성을 검증하기 위해 VO를 도입하게 되었다.

VO(Value Object)란?

도메인에서 한 개 또는 그 이상의 속성들을 묶어서 특정 값을 나타내는 객체, 즉 값을 나타내기 위해서 쓰이는 객체

VO는 불변성을 보장해야한다.

• equals & hash code 메서드를 재정의 해야한다.
  • 값을 나타내기 위해서만 사용하므로 내부의 상태가 같다면 같은 값이여야한다.
• setter가 없어야한다.
  • VO의 존재이유는 값을 나타내기 위해서인데, 값이 계속 변한다면 이는 무의미하다.

참고참고

https://tecoble.techcourse.co.kr/post/2020-06-11-value-object/

https://youngjinmo.github.io/2021/04/dto-vo-entity/

3. 단일 책임 원칙 : SRP

SRP(Single Responsibility Principle)란?

말 그대로 하나의 클래스는 단 하나의 책임을 가진 다는 의미한다.

단일 책임 원칙을 지켜야 하는 이유는 응집도와 결합도로 설명할 수 있다.

• 응집도란 한 프로그램 요소가 얼마나 뭉쳐 있는가를 나타내는 척도이다.
• 결합도란 프로그램 구성 요소들 사이가 얼마나 의존적인지를 나타내는 척도이다.

여기서 의존이라는 것은 A 클래스에서 B 클래스의 메소드를 호출 할 때, A가 B에 의존한다고 한다.

하나의 책임을 가지는 데이터와 기능(데이터에 대한 조작) 응집되어 있을 수록 관리할 수 있는 범위가 적어진다.

결합도가 낮아지면 의존성도 낮아진다.

완성도 있는 프로그램을 만들기 위해서는 유지보수가 꼭 필요하고, 유지보수를 할 때 변경은 필수 요소이다.

그러므로 응집도가 높고 결합도가 늦을 수록 변경의 대상이 적어지기때문에 유지보수가 더 수월해지는 것이다.

참고참고

SOLID 1편 SRP와 OCP

객체지향의 올바른 이해 : 7. 의존(Dependency)과 책임(Responsibility)

4. stream은 물줄기가 아니야!

• 가장 상위가 origin, 가장 하위가 local, 위로 갈 수록 upstream(-u 할때 그 u가 upstream이다)