작성한 질문수 3

0

안녕하세요, his130님.
만약 Fan을 실행하기 위해, 아얘 매개변수까지 넣을 정도의 변화가 생기는 상황이라면
애초에 Switchable 인터페이스를 사용하면 안 될 것입니다. 그땐 완전히 다른 설계가 필요하죠.
(현실에서 켜고 끄는 기능에 다른 뭔가 변수를 집어넣는 기기는 없죠.)
DIP는 말씀하신 상황을 위한 설계가 아닙니다.
지금 가정한 상황은, 온오프 기능이 있는 스위치 하나로 그 스위치가 적용되는 모든 기기를 끄고 켤 수 있도록 하는 것입니다. 그 스위치로 선풍기 뿐 아니라 전등, 제습기 등등을 모두 사용할 수 있게 하기 위해 스위처블 인터페이스를 사용하는 것이라고 생각하시면 되겠습니다. 즉, 켜고 끄기만 하면 되는 기기들 말이죠.

정리하자면 같은 기기에 기능이 바뀔 때가 아니라, 같은 기능의 새 기기가 추가될 때를 위한 설계인겁니다.

0

안녕하세요, 인프런 AI 인턴입니다. his130님!

DIP(Domain Interface Principle) 관련 질문을 해주셨군요. DIP는 고수준 모듈이 저수준 모듈에 의존하기보다는 추상화에 의존하도록 하는 설계 원칙입니다. 여기서 Switchable 인터페이스는 추상화 요소로, 다양한 객체가 이 인터페이스를 구현할 수 있게끔 합니다.

질문해주신 대로, 만약 Fan 클래스의 turnOn 메서드가 오버로딩되어 매개변수를 추가하게 된다면, Switch 클래스의 turnOn 메서드에도 간접적인 영향이 갈 수 있습니다. 이때 device.turnOn()이 Fan의 특정한 오버로딩된 메서드를 호출하도록 수정할 필요가 있을 겁니다.

하지만 DIP 원칙을 잘 지킨다면, Switch 클래스의 코드를 직접 수정하지 않고도 이를 해결할 수 있는 설계를 고려해야 합니다. 예를 들어, 전략 패턴(Strategy Pattern)을 활용해 Switch 클래스를 수정하지 않고도 오버로드된 메서드를 호출할 수 있는 방법을 생각해 볼 수 있습니다.

혹시 얄코의 강의 내 DIP나 관련된 질문이 있으시다면, 강의 내 질문 게시판에서 DIP와 관련된 예제나 질문의 답변들을 참고하실 수도 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.