Whiteship's Note

'Principle of Least Knowledge'에 해당되는 글 1건

  1. 2006.11.11 Principle of Least Knowledge (4)

Principle of Least Knowledge

Design Pattern : 2006.11.11 14:30


최소 지식 원칙이라고도 하고 데메테르의 법칙 이라고도 합니다. 둘 다 같은 말이지만 책에서는 법칙이라고 하기보단 원칙이라는 말이 더 어울리고 최조 지식이라는 말이 원리를 더 잘 나타내고 있기 때문에 최소 지식 원칙이라는 말을 사용하기로 했답니다.
디자인 원칙
최소 지식 원칙 - 정말 친한 친구하고만 얘기하라.
인연을 많이 맺으면 맺을 수록 인생이 고달파 지기 때문에 되도록이면 인연을 맺지 않으면서 다른 객체들에게 영향력을 행사하는 방법으로 네가지가 있습니다.
  • 객체 자체의 매소드 호출
  • 메소드에 매개변수로 전달된 객체의 메소드 호출
  • 그 메소드에서 생성하거나 인스턴스를 만든 객체
  • 그 객체에 속하는 구성요소
이렇게 책에는 씌여있는데 영회 형의 옛날 블러그를 통해 찾은 c2.com에 있는 문서에 보면 다음과 같이 나와 있습니다.
  • You can play with yourself.
  • You can play with your own toys (but you can't take them apart),
  • You can play with toys that were given to you.
  • And you can play with toys you've made yourself.
순서가 조금 바꼈지만 무엇이 무엇을 번역한 것인지는 대충 짐작이 갈 것입니다. c2.com에 있는 문서에 보시면 약간 더 풀어서 설명한 글을 제공해 줍니다.

이 원칙을 위배하는 것 중에 가장 눈에 잘 띄는 모양은 줄줄이 비핸나 쏘세지 입니다. 그리고 객체 없이 그냥 호출하는 static 메소드들(facotory 패턴의 메소드나, singleton 패턴에 있는 메소드)입니다.

책에 나온 예제 소스코드 입니다.

색칠 된 부분 모두 원칙에 위배되지 않습니다. 분홍색 부분은 두번째 줄에 해당하고 하늘색 부분은 세번째 줄에 해당하고 녹색은 네번째 줄에 해당하고 노란색은 첫번째 줄에 해당합니다.

위배되는 경우의 코드를 보겠습니다.

분홍색 부분이 이 원칙을 배신하고 있습니다. 객체에 연쇄적으로 메소드를 호출하게 됐을 때.. 즉 위의 경우 getThermomoeter()를 호출 했을 때 받아오는 객체의 내용이 만약 바뀌게 된다면 잇따라 호출한 getTemperature() 메소드를 호출하지 못할 수도 있는 경우가 발생할 수도 있겠지요. 영회형 블러그에 있던 글을 인용하자면
그렇게 되면 설계 과정에서 관계가 강하지 않다고 떼어놓은 것에
다시 결합도(coupling)을 부여하는 결과가 되니까..
이런 모양을 원했는데...

요로케 된다는 뜻이 아닐까.. 생각해 봅니다.

위의 코드를 아래와 같이 수정하면 원칙을 따르게 됩니다.


볼 거리 :
http://www.headfirstlabs.com/phpBB2/viewtopic.php?p=590&sid=70caa5b5a3b7d4ea2ed2d8e79a938635
-> 책의 이 부분에 대한 head first 포럼에 올라왔던 글입니다. 별로 재밌진 않네요. -_-;;
영회 형 예전 블러그의 글
-> 재밌지요. 다른 원칙들도 같이 정리되어 있습니다.
c2.com에 있는글
-> 이만한 자료를 찾을 수가 없었습니다. 더 좋은 자료 찾으시면 알려주세요.


top

  1. Favicon of http://zerry82.tistory.com BlogIcon 현동규 2006.11.11 19:15 PERM. MOD/DEL REPLY

    그렇게 되면 설계 과정에서 관계가 강하지 않다고 떼어놓은 것에
    다시 결합도(coupling)을 부여하는 결과가 되니까..


    형 이부분이 잘 이해가 안가요 -0-;;;;

    수정전이나, 수정후나 둘다 Themometer 와 결합도가 있는것 아닌가요?

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2006.11.11 22:51 신고 PERM MOD/DEL

    "원격을 통해 얻었거나 글로벌 혹은 싱글턴 객체를 통해 얻은
    객체에 대해 직접 호출을 하지 말라는 의미인 듯

    그렇게 되면 설계 과정에서 관계가 강하지 않다고 떼어놓은 것에
    다시 결합도(coupling)을 부여하는 결과가 되니까.. "

    이게 영회형 블러그에 있던 원문이지... 내가 이해한데로 그림을 추가했는데..

    수정후에 해당하는 코드가 너의 말대로 결합도를 낮춘것 같진 않구나..

    단지 "최소 책임 원칙"을 지켰다는 정도? 그 정도밖에는 아직 모르겠군..

  2. Favicon of http://zerry82.tistory.com BlogIcon 현동규 2006.11.11 23:41 PERM. MOD/DEL REPLY

    예.. 암튼 이걸로 인해서 얻을수 있는 장점은요

    책에도 나와있듯이

    객체들 사이의 의존성을 줄이고, 소프트웨어 관리가 더 용이해질수 있다네요.

    생각을 해보면 프로그래밍 세계는 종나 아리송하기 때문에..

    언제나 변할수 있거든요.. 에자일에서도 변화에 유연하게 대처하기 위해선

    깔끔한 코드를 가져야 한다는데. 이 원칙이 깔끔한 코드를 만들수 있도록

    도와 줄것 같아요.

    만약에 제공하는 클래스가 갑자기 변경되서

    station.getThermometer().getTemperature();

    이 코드가 갑자기 에러가 난다면??

    getThermometer()가 에러인가? getTemperature()가 에러인가??

    라는 혼동이 오겠죠.. 유연하게 대처하기 힘들 것입니다.

    하지만 위처럼 최소 지식 원칙을 이용하여 만든 코드에서는

    에러가 나는 구간을 빨리 파악을 할수 있겠네요.


    그런데 단점도 서술되어 있네요.

    "다른 구성요소에 대한 메소드 호출을 처리하기 위해 "래퍼" 클래스를 더

    만들어야 할 수도 있습니다. 그러다 보면 시스템이 더 복잡해지고,

    개발 시간도 늘어나고, 성능이 떨어질수도 있습니다."



    그렇기 때문에 주변에 상황에 따라 쓰여야 한다고 합니다.



    그런데요.. 저 같으면 책에서처럼 코딩 안하고 이렇게 하겠습니다.

    public float getTemp( ){

    Thermometer thermometer = station.getThemometer();

    float temperature = thermometer.getTemperature();

    return temperature;
    }

    이것도 최소 지식 원칙에 어긋 안나고,

    에러가 난다해도 유연하게 대처 할수 있지 않을까요?-0-;;;;


    Favicon of https://whiteship.tistory.com BlogIcon 기선 2006.11.13 10:17 신고 PERM MOD/DEL

    비록 메소드가 많아 지더라도 잘게 쪼개 놓는게 리팩토링 할 때 좋치.. 아마 그래서 나눠 논건 아니고..매개변수로 넘겨 받은 객체의 메소드 콜을 하는 것은 원칙에 어긋나지 않기 때문에 본문에서는 그렇게 해둔거 같고...

    너가 생각한 방시대로 해도 무방하다고 생각이 되네..ㅋㅋ

Write a comment.