이러한 메소드를 사용하는 클라이언트 코드를 손상시키지 않기 위해 API / 공용 메소드 서명의 변경이 최소화되어야한다는 점을 감안할 때 Demeter of Law 가 적용되지 않는지 궁금했습니다 .
간단한 예 :
class Account() {
double balance;
public void debit(Transaction t) {
balance -= t.getAmount();
}
}
debit 메소드는 단지 두 배의 금액이 아닌 Transaction 객체를 전달합니다. ( 'Law of Demeter')는 필요한 정보를 전달한다고 말합니다 (이 경우 Transaction 객체가 아닌 금액). ). 그 이유는 나중에 메소드에 금액 외에 다른 트랜잭션 속성이 필요할 수 있기 때문입니다. 내가 이해 한 바에 따르면, 앞으로 새 매개 변수를 추가하여 메서드 서명을 위반하지 못하게됩니다.
이것이 현명한 선택입니까? 아니면 뭔가 빠졌습니까?
답변:
그러나 이것은 데메테르의 법칙을 위반하지 않습니다.
보다 공식적으로, 함수에 대한 Demeter of Law는 객체 O의 메소드 M이 다음과 같은 객체의 메소드 만 호출 할 수 있어야합니다.
- O 자체
- M의 매개 변수
- M 내에서 생성 / 인스턴스화 된 객체
- O의 직접 컴포넌트 객체
- M의 범위에서 O에 의해 액세스 가능한 전역 변수
위키 백과 : 데메테르의 법칙
Transaction은 debit 메소드의 인수이므로 t.getAmount ()를 호출하는 것이 좋습니다.
편집 : LoD가 Transaction 객체가 아닌 거래 금액을 전달해야한다고 잘못 알고 있습니다. 그렇다면 그렇다면 나중에 Transaction 객체에서 더 많은 것이 필요하다는 것을 알기 때문에 이것을 깨기 좋은 곳이라고 생각합니다. 또한 도메인 레벨 객체에 프리미티브를 캡슐화하는 것도 좋은 프로그래밍 실습입니다.
편집 2 : 읽기 데 힘을 더 미래의 필요를, 하나는 불필요한 금 도금으로 이것을 볼 수 있었다. 지금 두 배 (또는 더 나은 Money 클래스)를 취하는 방법을 제공하면 충분합니다. 나중에 Transaction 인수가 필요하면 Transaction을 취하는 두 번째 서명을 제공하는 것이 비참한 것이 아니라 원래 서명을 계속 지원하는 것입니다. 두 가지 방법을 구현하는 것은 아닙니다. 하나는 다른 하나를 호출합니다.
Account앞으로 수업 을 확장 할 계획이라면 , 이것이 Transaction객체를보다 일반적인 목적으로 만드는 것이 법의 규칙 을 제대로 구부리는 상황이라고 말하고 싶습니다 .
예를 들면 다음과 같습니다.
public class Amount {
public void process( Transaction t ) {
....
}
}
public abstract class Transaction {
public String getType();
}
나는 원래의 질문에서 벗어나고 있다고 생각하지만, 내 요점은 당신이 데메테르 법칙에서 벗어나고 있다고 걱정할 수 있지만, 그렇게하는 것의 장점은 부정적인 것보다 중요하다는 것입니다.