2012-07-24 3 views
1

'외관 패턴'을 사용하여 인터페이스를 설계하려고합니다. 그러나으로 여기에 지적이 클래스의 접근 방법을 많이 만들어 내게 강요최소한의 지식을 사용하면서 많은 방법을 만드는 것을 피하는 방법은 무엇입니까?

http://www.scribd.com/doc/6599003/7/Principle-of-Least-Knowledge-PLK

. 위의 링크에 따르면 PLK의 변형으로 구체적인 객체를 참조하는 것과 반대되는 인터페이스 참조를 반환 할 수 있습니다.

제 질문은 어떻게 문제를 해결할 수 있습니까? 인터페이스 참조를 반환하면 적절한 클래스로 인스턴스화해야합니다. 궁극적으로 우리는 그 객체로부터 메소드를 호출하게 될 것입니다.

+0

Facade 패턴을 사용하는 경우 오브젝트는 랩핑 된 오브젝트의 사용을 단순화하는 것입니다. Facade 자체는 상당히 복잡 할 수 있습니다. 래핑 된 객체 나 인터페이스 중 하나를 직접 노출하는 경우 파사드를 사용하는 것이 중요하지 않습니다. – BonyT

답변

0

특정 패턴을 사용하여 인터페이스를 설계한다고 말하면은 이유를 모른 채 패턴을 사용하는 것처럼 들립니다. 해결하려는 디자인 문제가 있습니까? 그렇다면 인터페이스를 반환하면 문제가 해결되는지 아닌지는 분명합니다.

이름에서 알 수 있듯이 외관 패턴은 발신자에게 표시되지 않게하려는 것을 숨기는 데 사용됩니다. 무언가를 숨길 수있는 좋은 이유는 복잡합니다. 복잡한 코드가있는 경우 호출자에게 단순한 인터페이스를 제공하는 외관 뒤에있는 복잡성을 숨길 수 있습니다. 호출자와 호출 된 코드 간의 결합이 느슨하기 때문에 좋습니다. 구현 세부 사항이 변경되면 외관 변경 내용을 숨길 수 있으며 호출자는 신경 쓸 필요가 없습니다.

무언가를 숨기는 방법 중 하나는 정확한 유형을 숨기는 것입니다. BarBaz을 구현하는 클래스 FooBaz에 선언 된 메소드를 사용해야하는 호출자가 있다고 가정 해 보겠습니다. 그런 다음 복잡성을 숨기는 한 가지 방법은 "Baz을 구현하는 것"과 같은 인터페이스 만 반환하는 것입니다. 그러면 발신자는 Foo 또는 Bar을 신경 쓸 필요가 없으며 더 나은 경우 발신자는 Foo 또는 Bar을 모두 사용할 수 없습니다.. 원하는대로 FooBar을 자유롭게 변경할 수 있습니다. 이는 좋은 것입니다.

관련 문제