oop에서 클래스가 다른 어느 메서드를 알고 있을까..라는 화두는 상당히 중요함
인터페이스로 묶어놓은 적당한 결합력은 쉬운 유지보수를 위할때 강력한 조력자가 되기 때문임
예를들어 돈넣기와 음료뽑기 메서드가 포함된 자판기 인터페이스가 있고, 커피자판기와 음료자판기가 이 인터페이스를 구현했다고 하자
public 음료 음료사기(자판기 vendor){
vendor.돈넣기();
음료 drink = vendor.음료뽑기();
return drink
}
'음료사기'라는 메서드는 파라미터로 인터페이스인 자판기를 받고 있음.
이 메서드는 파라미터로 받을 자판기가 음료자판기인지 커피자판기인지 아니면 자판기를 구현한 또 다른 클래스인지 알지 못함
이렇게 음료사기 메서드가 자신이 받아올 클래스가 구체적으로 모를 경우 재사용성이 뛰어나다고 말할 수 있음.
자신이 사용할 클래스를 정확이 모르면 교체가 가능하기 때문에 부품으로써의 가치가 높음.
이 교환가능성은 여러가지 패턴을 사용할때 주 레시피가 되기 때문에 클래스 설계자는 접근제한자의 조합에 대해 항상 기억할 필요가 있음
인터페이스로 묶어놓은 적당한 결합력은 쉬운 유지보수를 위할때 강력한 조력자가 되기 때문임
예를들어 돈넣기와 음료뽑기 메서드가 포함된 자판기 인터페이스가 있고, 커피자판기와 음료자판기가 이 인터페이스를 구현했다고 하자
public 음료 음료사기(자판기 vendor){
vendor.돈넣기();
음료 drink = vendor.음료뽑기();
return drink
}
'음료사기'라는 메서드는 파라미터로 인터페이스인 자판기를 받고 있음.
이 메서드는 파라미터로 받을 자판기가 음료자판기인지 커피자판기인지 아니면 자판기를 구현한 또 다른 클래스인지 알지 못함
이렇게 음료사기 메서드가 자신이 받아올 클래스가 구체적으로 모를 경우 재사용성이 뛰어나다고 말할 수 있음.
자신이 사용할 클래스를 정확이 모르면 교체가 가능하기 때문에 부품으로써의 가치가 높음.
이 교환가능성은 여러가지 패턴을 사용할때 주 레시피가 되기 때문에 클래스 설계자는 접근제한자의 조합에 대해 항상 기억할 필요가 있음
- dc official App
열심히 쓴거같은데 미안한데 니 예가 틀린 객체지향이다 음료클래스안에 음료사기가 있으면 안된다 생각좀더해봐
ㄴㄴ 음료클래스 아냐 음료사기라는 메서드의 리턴타입이 음료라는 뜻임 - dc App
어제 누가 인터페이스를 어떻게 인자로 전달함?? 라고 쓴 글이 생각나서 잠깐써봄 - dc App
음료사기 클래스가 존재할 필요가 있을까 싶은데 쨋든 ㅇㅋ
시발
음료를 산다는건 행동이면 메소드로 들어가야지 클라스로 빼는 이유가;;
아니 쉬발 저거 클래스로 뺀거 아니라니까 그냥 예시 메서드임 메서드 한개가 끝임 - dc App
한글로 갖다붙이면 가독성 좃될줄 알았는데 다른 의미로 좃됫나보네 - dc App
이런건 말로 하지 말고 코드로 써라. 원래 사람의 언어보다 프로그래밍 언어가 훨씬 정제되고 발전된 체계를 가짐
겨우 저걸 다형성이라고 하기에는 너무 좁은 비유인데 - dc App