이것을 실제로 살펴 보자
Obj 3이제 Obj 4존재한다는 것을 안다 . 그래서 무엇? 우리는 왜 걱정합니까?
딥 말한다
"높은 수준의 모듈은 낮은 수준의 모듈에 의존해서는 안됩니다. 둘 다 추상화에 의존해야합니다."
그러나 모든 객체 추상화가 아닙니까?
복각은 또한 말한다
"추상은 세부 사항에 의존해서는 안된다. 세부 사항은 추상화에 의존해야한다."
그러나 객체가 올바르게 캡슐화되어 있으면 세부 정보가 숨겨지지 않습니까?
어떤 사람들은 모든 객체에 키워드 인터페이스가 필요하다고 맹목적으로 주장하기를 원합니다. 나는 그들 중 하나가 아닙니다. 나는 당신이 그것들을 지금 사용하지 않는다면 나중에 그들과 같은 것을 필요로하는 계획이 필요하다고 맹목적으로 주장하고 싶다.
모든 릴리스에서 코드를 리팩터링 할 수있는 경우 나중에 필요한 경우 인터페이스를 추출 할 수 있습니다. 다시 컴파일하고 싶지 않은 인터페이스를 통해 코드를 게시하고 인터페이스를 통해 대화하기를 원하는 경우 계획이 필요합니다.
Obj 3Obj 4존재한다는 것을 안다 . 그러나 구체적인 Obj 3것인지 아십니까 Obj 4?
이것이 바로 여기 new어디에나 퍼지지 않는 것이 좋은 이유 입니다. 만약 Obj 3알고하지 않습니다 Obj 4나중에에 몰래 설정되어있는 경우 그 다음, 그것을 작성하지 않은 것 때문에, 콘크리트입니다 Obj 4추상 클래스에 Obj 3상관하지 않을 것입니다.
그렇게 할 수 있다면 Obj 4완전히 추상적 인 것입니다. 처음부터 그들 사이에 인터페이스를 만드는 유일한 방법은 누군가 Obj 4가 현재 구체적으로 제공하는 코드를 실수로 추가하지 않을 것이라는 확신입니다 . 보호 된 생성자는 해당 위험을 완화 할 수 있지만 다른 질문이 발생합니다.
Obj 3과 Obj 4는 같은 패키지에 있습니까?
객체는 종종 패키지, 네임 스페이스 등의 방식으로 그룹화됩니다. 그룹화 할 때 그룹 전체가 아닌 그룹 내에서 영향을 미칠 가능성이 더 높습니다.
기능별로 그룹화하고 싶습니다. 경우 Obj 3와 Obj 4같은 그룹 및 레이어에있는 당신이 하나를 출판뿐만 아니라 다른 하나를 변경할 필요가 동안을 리팩토링 할거야 매우 가능성이 있습니다. 즉, 이러한 객체는 명확한 요구가 있기 전에 객체 사이에 추상화를 적용하면 이점이 적습니다.
그룹 경계를 넘어 서면 양쪽의 객체가 독립적으로 변하게하는 것이 좋습니다.
간단하지만 불행히도 Java와 C #은 이것을 복잡하게 만드는 불행한 선택을했습니다.
C #에서는 I접두어로 모든 키워드 인터페이스의 이름을 지정하는 것이 일반적 입니다. 이를 통해 고객은 키워드 인터페이스와 대화하고 있음을 알 수 있습니다. 그것은 리팩토링 계획을 어지럽 힙니다.
Java에서는 더 나은 이름 지정 패턴을 사용하는 것이 일반적입니다. FooImple implements Foo그러나 Java는 키워드 인터페이스를 다른 2 진으로 컴파일하기 때문에 소스 코드 레벨에서만 도움이됩니다. 즉 Foo, 한 문자의 코드 만 변경 될 필요가없는 구체적 클라이언트에서 추상 클라이언트로 리팩토링 할 때 여전히 다시 컴파일해야합니다.
사람들이 실제로 필요할 때까지 공식적인 추상화를 할 수 없도록하는 것은이 특정 언어의 버그입니다. 사용중인 언어는 말하지 않았지만 이러한 문제가없는 언어가 있다는 것을 이해하십시오.
사용중인 언어를 말하지 않았으므로 언어와 상황을 신중하게 분석하여 모든 곳에서 키워드 인터페이스가 될 것이라고 결정하기를 촉구합니다.
YAGNI 원칙은 여기서 중요한 역할을합니다. 그러나 "발로 자신을 쏠 수 없도록하십시오".
