Demeter의 법칙 - 실제 문제

Question

현실 세계에서 Demeter의 법칙을 이해하려고 노력하고 있습니다. 그러나 나는 사슬을 사퇴 할 때 얻을 수있는 이유와 이점에 대해 약간 혼란 스럽습니다. 책임.

나는 사용법을 고려하고있는 예제가있다. 관계

Enquiry -> assignedTo -> Room Rooms -> assignedTo -> Building Building -> assignedTo -> Company

지금은, 예를 일부 회사 데이터에 접근 할 필요가

와 클래스가 있습니다. 회사 이름을 입력하고 문의 할 수 있습니다. 따라서 현재 흐름은 다음과 같습니다. enquiry.getManager().getRoom().getBuilding().getCompany().getName() - 꽤 오래, 그렇지 않습니까?

나는 그것이 enquiry.getHostingCompanyName()로 변경해야하지만 내가 room.getHostingCompanyName() 및 building.getHostingCompanyName()가 선행 만들 필요가 날 것으로 보인다, 그 결과, 매우 깨지기되고보다 훨씬 더 많은 변화가 필요합니다 디테일 정도 따르는 경우 내 생각 리팩토링과 관련된 이전 접근

어떤 조언을 해 주실 수 있습니까? 아니면 내 가정이 완전히 틀렸고 다른 방식으로 수행해야합니까?

Answer 1

오브젝트는 사용하지 않고 데이터 구조 만 사용합니다. 당신은 같은 것을 쓰기 :

new Human().getStomach().getContent().insert(new Cake()); 

대신/캡슐 내부 구조를 숨기고, 도메인 특정 API를 노출한다 실물

new Human().eat(new Cake()); 

의. 또한 나에게 그것은 룸이 회사를 포함한다는 것이 이상하지 않다.

내 생각에 방은 회사를 알지 않아야하며 회사 개체에서 방 참조를 얻어야합니다.

개체 구조가 데이터베이스에 의해 유도되는 것처럼 보이지만 좋지 않습니다.

위의 모든 내용은 리치 도메인 시스템에 적용될 때 의미가 있으며 일부 사소한 CRUD에는 적용되지 않습니다. CRUD 시스템에서는 데이터 구조가 더 잘 작동합니다.

는

Answer 2

the Law of Demeter (또는 the Principle of Least Knowledge)의 실제 문제는 이런 식입니다 :

오 drat이 바로 실현 건물은 항상 하나 개의 기업에 할당되지 않습니다. 이 클래스의 인터페이스를 변경해야합니다. 그게 큰 변화 야. 이 클래스 친구들을 반올림하여 변경하고 ... 왜 101 개의 오류가 발생하는 이유는 무엇입니까? 한 명의 반은 몇 명의 친구가 필요합니까?

Demeter의 법칙은 실제로 캡슐화에 관한 것입니다. 그것은 당신이 많이 듣지 않는 캡슐화의 일종입니다. 일반적으로 캡슐화는 객체에있는 것입니다. 여기에는 객체 자체에 대한 지식이 있습니다.

개체에 세계 다른 국가와 거래하는 소수의 친구가 있으므로 개체가 공개 되더라도 실제로 캡슐화됩니다. 외부 세계의 객체가 해당 친구를 통해 객체에 도달하면 이는 사실이 아닙니다. 이제 당신의 물건은 어떤 물건이라도 알 수 있습니다. 고칠 것이 많습니다. 사물들은 친구들 뒤에 숨어 있습니다. 인기가 있기를 원하지 않습니다. 그들은 친한 친구 몇 명을 위해 약간의 일을하고 싶어합니다. 그들은 캡슐화되기를 원합니다.

친구의 친구에게 캡슐화를 무언가를하도록 요청해야하는 이유가 여기에 있습니다. 친구들에게 당신을 위해 일을하고 친구가 누구인지 걱정하지 말아야합니다. 너는 친구가 충분 해.

당신이 필요로하는 것을 얻기 위해 자신의 필요를 채워줄 필요가있는 경우, 당신이 도달하고있는 수업조차 알지 못하게하는 일부 작업이 취소되었음을 의미합니다. 일을하고 모든 일에 너무 친절하지 마라.

더 많은 정보가 필요하면이 before에 대해 실제로 작성했습니다.