객체의 종류 VO vs DTO vs Entity
- 객체는 단순히 데이터를 저장만 하는 건 아니다.
- VO : value Object의 약자로 값이 변할 수 없는 객체를 의미합니다.
- VO의 예시입니다. 값이 변하지 않기 때문에, 개발의 복잡성을 낮출 수 있습니다.
- 생성자는 두개의 역할만 하는 것이 좋습니다.
- DTO : Data Transfer Object 데이터 전송 객체를 의미하고, 모든 속성을 노출하는 것이 가능하다.
- 간단히 설명을 덧붙히자면, DTO는 파라미터 하나씩 작성하여 데이터를 보내는 것이 번거러우니, 하나의 객체러 묶여서 처리합니다.
-
Entity : 유일한 식별자가 있고, 수명 주기가 있으며, 저장소에 저장한다는 특징이 있습니다.
-
또한 무조건 DB와 연동된다는 건 아니기 때문에, DB와 관련없이 Entity를 사용할 수 있습니다.
-
객체라는 건 3종류만 있는 것이 아니며, 완벽한 분류는 어렵습니다. 따라서 VO면서 DTO면서 Entity일 수 있습니다.
디미터 법칙
-
최소 지식의 법칙 : 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다.
-
각 디스크 용량을 출력하는 것보다는 디스크 전체 용량을 출력하는 것이 디미터 법칙에 적용된다.
행동
자동차 클래스를 만든다.
개발자 A는 바퀴, 프레임, 엔진, 방향, 속도 값을 갖고 있어야겠다.
개발자 B는 자동차는 달릴 수 있어야하고, 속도를 조절할 수 있어야하고, 방향을 바꿀 수 있어야해.
- 개발자 B가 좀 행동 위주의 사고를 하여 객체지향적 사고를 했다고 볼 수 있다.
-
Duck typing : 행동이 같다면 같은 클래스로 부르겠다.
-
예시로 행동을 오리처럼 한다면 모르는 새는 오리라고 하겠다는 의미입니다.
순한 참조
-
순한 참조는 논ㄴ리적으로 여러 도메인에 존재하며 설계에도 필요하지만 순한 참조를 유지하는 데는 신중을 기해야 한다.
-
순한 참조가 부자연스러운 이유 :
-
순한 의존성이 있다는 것 자체가 사실 그 둘은 하나의 클래스여야 했다는 것이다.
- 위 그림을 보면 Feed 클래스는 User를 참조하고 있습니다. 글을 세개를 쓰고 결과를 Json으로 도출하면 이런 식으로 결과가 발생하여 에러가 발생합니다.
- 위 방식으로 해결이 가능합니다.
- 순환참조를 해야하는 상황이라면 위 방식으로 분리를 하는 방식을 만드는 것이 오류를 줄입니다.
변화를 두려워하는 사람이 가장 불행한 사람이다.