From f1140e7537526c2a4fc62854e52c4e562394dcf5 Mon Sep 17 00:00:00 2001 From: Two-Jay Date: Mon, 18 Dec 2023 18:05:09 +0900 Subject: [PATCH 1/3] =?UTF-8?q?=EB=94=94=EB=AF=B8=ED=84=B0=EC=9D=98=20?= =?UTF-8?q?=EB=B2=95=EC=B9=99=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/README.md b/README.md index efcdadc0..dbc9ead5 100644 --- a/README.md +++ b/README.md @@ -38,6 +38,7 @@ * [스포티파이 모델](#스포티파이-모델) * [와들러의 법칙](#와들러의-법칙) * [휘턴의 법칙](#휘턴의-법칙) + * [디미터의 법칙](#디미터의-법칙) * [원칙](#원칙) * [딜버트의 법칙](#딜버트의-법칙) @@ -621,6 +622,24 @@ _성급한 최적화_ 란 (좁은 의미로) 그것이 꼭 필요한지 알기
+### 디미터의 법칙 + +[The Law of Demeter on Wikipedia](https://en.wikipedia.org/wiki/Law_of_Demeter) + +> 모든 사소하지 않은 추상화는, 어느 정도, 허술하다. +> +> —조엘 스폴스키 + +이 법칙에 따르면 컴퓨팅에서 복잡한 시스템과 작업하기 위해 일반적으로 사용되는 추상화에서는 때에 따라 하단 요소의 '누수'가 일어날 수 있고, 이는 추상화가 예상치 못한 방향으로 전개되게 한다. + +파일을 불러와 내용을 읽는 상황을 살펴보자. 파일 시스템 API는 로우 레벨 커널 시스템의 _추상화_ 인데, 이 시스템 또한 자기 플래터(혹은 플래시 메모리나 SSD)의 데이터를 물리적으로 변경하는 것의 추상화이다. 대부분의 경우 파일을 이진 데이터의 스트림으로서 추상화하는 것은 문제가 없을 것이다. 그러나 자기 디스크에서는 데이터를 순서대로 읽는 것이 임의 접근보다 *비교할 수 없을 만큼* 빠른 반면에(페이지 폴트 비용 때문에), SSD에서는 전혀 상관이 없다. 내부 구현을 상세히 이해하여야 이런 경우에 대처할 수 있는데(가령, 데이터베이스 인덱스 파일은 임의 접근의 비용을 줄이도록 구조가 짜여져 있다), 이렇듯 추상화는 개발자가 모르면 곤란하도록 내부 구현 상세를 '누출'한다. + +위의 예시는 _더 많은_ 추상화가 도입되면 더욱 복잡해질 수 있다. 리눅스 운영체제는 네트워크를 경유하여 파일에 접근할 수 있도록 하면서도 로컬에서는 '일반' 파일로 취급한다. 이런 추상화는 네트워크 오류가 발생하면 '허술해질' 것이다. 만약 개발자가 이런 파일들을 네트워크 지연이나 오류에 대한 고려 없이 '일반' 파일로 취급한다면, 버그가 생길 것이다. + +이 법칙을 설명하는 글에 따르면 하부 구동 원리를 모른 채로 추상화에 과도하게 의존할 경우, 도리어 문제 해결을 복잡하게 만들 수 있다고 하고 있다. + +
+ ## 원칙 원칙들은 일반적으로 설계의 가이드라인과도 같다. From dd5b7315de8a0801a4f63e290715edf5cc735b68 Mon Sep 17 00:00:00 2001 From: Two-Jay Date: Mon, 18 Dec 2023 18:14:35 +0900 Subject: [PATCH 2/3] =?UTF-8?q?=EC=BB=A8=ED=8A=B8=EB=A6=AC=EB=B7=B0?= =?UTF-8?q?=ED=84=B0=20=EB=AA=A9=EB=A1=9D=20=EC=97=85=EB=8D=B0=EC=9D=B4?= =?UTF-8?q?=ED=8A=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CONTRIBUTORS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md index 515e77de..df0e64ad 100644 --- a/CONTRIBUTORS.md +++ b/CONTRIBUTORS.md @@ -1 +1,2 @@ - [rheh](https://github.com/rheh) - Suggestion - Brooks's Law +- [Two-Jay](https://github.com/Two-Jay) - PR - The Law of Demeter \ No newline at end of file From 0dec8424b099621eeb1baf7e2ed0e99904e25a42 Mon Sep 17 00:00:00 2001 From: Two-Jay Date: Mon, 18 Dec 2023 18:15:48 +0900 Subject: [PATCH 3/3] refresh --- README.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index dbc9ead5..fe0dd5eb 100644 --- a/README.md +++ b/README.md @@ -624,19 +624,20 @@ _성급한 최적화_ 란 (좁은 의미로) 그것이 꼭 필요한지 알기 ### 디미터의 법칙 -[The Law of Demeter on Wikipedia](https://en.wikipedia.org/wiki/Law_of_Demeter) +[The Law of Demeter](https://www2.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/general-formulation.html) -> 모든 사소하지 않은 추상화는, 어느 정도, 허술하다. +> 낯선 이와 대화하지 말라. > -> —조엘 스폴스키 +> 화자 미상 -이 법칙에 따르면 컴퓨팅에서 복잡한 시스템과 작업하기 위해 일반적으로 사용되는 추상화에서는 때에 따라 하단 요소의 '누수'가 일어날 수 있고, 이는 추상화가 예상치 못한 방향으로 전개되게 한다. +최소 지식 원칙이라고도 부르는 디미터의 법칙은, 객체지향 프로그래밍에서 책임에 대한 캡슐화와 느슨한 커플링을 다룰 때에 중요하게 여겨지는 법칙이다. 이는 특정한 객체의 메소드에서 정보를 다룰 때 직접적으로 알고 있는 대상만을 호출함으로써 책임이 적절하게 분배되지 않거나 복잡한 커플링을 가져서 발생하는 문제를 방지할 수 있도록 유도한다. -파일을 불러와 내용을 읽는 상황을 살펴보자. 파일 시스템 API는 로우 레벨 커널 시스템의 _추상화_ 인데, 이 시스템 또한 자기 플래터(혹은 플래시 메모리나 SSD)의 데이터를 물리적으로 변경하는 것의 추상화이다. 대부분의 경우 파일을 이진 데이터의 스트림으로서 추상화하는 것은 문제가 없을 것이다. 그러나 자기 디스크에서는 데이터를 순서대로 읽는 것이 임의 접근보다 *비교할 수 없을 만큼* 빠른 반면에(페이지 폴트 비용 때문에), SSD에서는 전혀 상관이 없다. 내부 구현을 상세히 이해하여야 이런 경우에 대처할 수 있는데(가령, 데이터베이스 인덱스 파일은 임의 접근의 비용을 줄이도록 구조가 짜여져 있다), 이렇듯 추상화는 개발자가 모르면 곤란하도록 내부 구현 상세를 '누출'한다. +디미터의 원칙에 따르면 호출하는 객체가 c이고 메소드가 f 일때 객체의 메소드 f는 아래의 4가지만 호출할 수 있다. -위의 예시는 _더 많은_ 추상화가 도입되면 더욱 복잡해질 수 있다. 리눅스 운영체제는 네트워크를 경유하여 파일에 접근할 수 있도록 하면서도 로컬에서는 '일반' 파일로 취급한다. 이런 추상화는 네트워크 오류가 발생하면 '허술해질' 것이다. 만약 개발자가 이런 파일들을 네트워크 지연이나 오류에 대한 고려 없이 '일반' 파일로 취급한다면, 버그가 생길 것이다. - -이 법칙을 설명하는 글에 따르면 하부 구동 원리를 모른 채로 추상화에 과도하게 의존할 경우, 도리어 문제 해결을 복잡하게 만들 수 있다고 하고 있다. +- c, 즉 객체 자기자신 +- f가 생성한 객체 +- f에 매개변수로 전달된 모든 정보 +- 객체 c의 인스턴스에 저장된 필드