혼자 개발을 할 때 가장 어려운 점 중 하나가 내 코드에 대한 피드백을 할 수 없다는 것이다.
향로가 공유해주셨던 트위터이다. 개발자가 성장했다는 것은 자기가 쓴 코드에서 무엇인가가 어색하다는 것을 느끼는 것에서부터 시작한다고 말하는데, 이 말에 크게 공감되었다. 코드 리뷰를 해주는 동료가 있다는 것은 내가 내 코드에서 떨어져나와 어색한 점을 찾는 것이니 코드리뷰는 개발자의 성장과 직결되어있다고 생각된다. 그리고 혼자 공부를 하면서 가장 어려웠던 점이기도 하므로, 코드리뷰를 받으며 배운 것에 대한 글도 꾸준히 올리려고 한다.
오늘 글에서 정리하려는 내용은 '디미터의 법칙(law of demeter)'이다.
디미터의 법칙을 위키에 찾아보면 AOP를 만들 때 생각된 개념인 것을 알 수 있다. AOP란 모듈성을 높이는 패러다임이다. (AOP 위키)
The Greek goddess of Agriculture.
The Demeter project was named after Demeter because we were working on a hardware description language Zeus and we were looking for a tool to simplify the implementation of Zeus. We were looking for a tool name related to Zeus and we chose a sister of Zeus: Demeter.
Later we promoted the idea that Demeter-style software development is about growing software as opposed to building software. We introduced the concept of a growth plan which is basically a sequence of more and more complex UML class diagrams.
Growth plans are useful for building systems incrementally.
그리스 농업의 여신. Demeter 프로젝트는 하드웨어 설명 언어 Zeus에 대해 작업 중이었고 Zeus 구현을 단순화하는 도구를 찾고 있었기 때문에 Demeter의 이름을 따서 명명되었습니다. Zeus와 관련된 도구 이름을 찾고 있었고 Zeus의 자매인 Demeter를 선택했습니다. 나중에 우리는 Demeter 스타일의 소프트웨어 개발이 소프트웨어를 구축하는 것이 아니라 소프트웨어를 성장시키는 것이라는 아이디어를 홍보했습니다. 우리는 기본적으로 점점 더 복잡한 UML 클래스 다이어그램의 시퀀스인 성장 계획의 개념을 도입했습니다. 성장 계획은 시스템을 점진적으로 구축하는 데 유용합니다.
(https://en.wikipedia.org/wiki/Law_of_Demeter)
AOP의 연장에서 나온 패러다임인 OOP의 중요한 개념 중 하나가 객체간의 의존성을 관리하는 것이다.
객체는 다른 객체가 어떻게 구현되어있는 지 몰라야 한다. 그냥 가져다쓰기만 해야한다. (이러한 원리로 다형성이 구현된다.)
그런데 '.'을 여러개 붙이면 객체 안에 있는 어떤 값 안에 있는 어떤 값이 있는 지 계속 찾아들어 간다.
비유하자면 우리 집 내부 사정은 다른 집에서는 몰라야 하는데, 우리집.부엌.냉장고.첫번째사랍.사과를 가져다 쓰는 것이 된다.
다른 집에서는 우리집에 사과가 어디 있는지, 있는 지 없는 지 조차 몰라야한다.
그래서 우리집.사과드릴게요 라고 바꿔서 집들 사이에 의존성을 낮추려고 하는 것이 디미터의 법칙을 적용시키는 방법이라고 할 수 있다.
위의 내용을 코드로 설명하면 다음과 같다.
school 이라는 객체 안에 private한 값으로 student가 들어있다고 생각하고, 이 student는 고유의 id가 있다고 가정한다.
school 객체 밖에서 student의 id를 가져다 쓰고 싶을 때 다음과 같이 하면 디미터 법칙을 지킬 수 있다.
객체(Entity)를 만들 때에 private한 값을 외부에서 가져다 쓸 수 있도록 매서드를 만드는데, 이 때 student.id를 리턴하는 매서드를 추가한다.
@Entity() <---------- 엔티티 객체에
get studentId(): number { <---------- private으로 되어 있는 값을 가져오는 get 매서드 추가
return this.student?.id || 0;
}
그리고 외부에서 가져다 쓸 때에 다음과 같이 쓴다.
- 는 내가 디미터 법칙을 지키지 않은 것이고
+는 이 부분을 리뷰 받아서 수정한 방법이다.
- this._studentId = school.student?.id;
+ this._studentId = scheel.studentId;
참고하고 있는 객체에 있는 변수 값인 this._studentId는 school 안에 student가 어떤 값을 가지고 있는지(여기서는 id) 관심이 없으며, studentId만 리턴 받으면 된다.
시간을 정하고 글을 쓰다보니 용두사미가 되었다.

레퍼
https://en.wikipedia.org/wiki/Law_of_Demeter
Law of Demeter - Wikipedia
From Wikipedia, the free encyclopedia Jump to navigation Jump to search Design guideline for developing software The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs.
en.wikipedia.org
'백엔드 개발 > 백엔드 일기' 카테고리의 다른 글
#007. 백엔드 성장일기: 주간 프리뷰(작은 동물 의자, 이별 휴가 등) (2) | 2022.04.20 |
---|---|
#006. 백엔드 성장일기: 안티패턴 return await (0) | 2022.04.19 |
#005. 백엔드 코드리뷰 : DTO에 엔티티 값을 그대로 사용하는 안티패턴 (0) | 2022.04.18 |
#004. 백엔드 성장 일기 : source tree (0) | 2022.04.15 |
#002: 글을 쓰기 시작하는 목적 두 가지 (2) | 2022.04.13 |