Q. 클래스를 직접 참조하면 안됨? 왜 인터페이스를 또 만들어서 그걸 참조함?
A. 변경하기 쉬우라고 만드는거임. 우리가 만약 Player 객체의 state를 바꾸는 함수를 setState(Player)로 만들었으면 이를 이용하는 객체는 반드시 Player와 호환되어야함. Caveman과 같은 다른 타입의 객체는 이 함수를 못 씀. setState에 넣어주기 위해 Player가 가지는 속성들도 구현해야하는거임. 실제로는 state를 가지는 집합인 IEntity를 인자로 받았으면 해당 인터페이스를 구현하는 모든 클래스의 인스턴스가 함수를 이용할 수 있음
Q. 앵 ㅅㅂ 바꿀일 없음 이거 Player '만' 가능하고 Player에 의존적인 코드가 많음
A. 절대란 없음. 가장 간단한 예로, 너가 테스트 코드를 작성한다고 하자.
실제로 Player 개체는 Stage와도 상호작용하고 있었다고 치자. 그럼 setState를 테스트하는 코드는 Stage와도 의존성이 생김. setState의 정상 작동을 확인하려면 Stage 개체도 만들어야함.
IPlayer를 를 인자로 받게 했다면 player를 모킹(가짜인데 진짜인척하는, 테스트용)하게끔 MockPlayer 클래스를 만들어서 IPlayer를 구현하게 하면 끝임. Stage와 의존성이 사라짐.
너가 어느날 PlayerGhost라는 비슷한 타입을 만들지도 모르는 일임.
Q. 그럼 그냥 그때 바꾸면 되는거 아님? 왜 미리 인터페이스를 만듦?
A. 그건 개인의 선택임. 결국 이런 분리가 단기적인 개발 비용에 영향을 주는건 사실이며 함수마다 인터페이스를 만드는것도 못할짓임. 적절히 추상화 수준을 정해야지.
다만 너가 Player를 그대로 박았고
그 함수를 수정해
다른 누군가가 Player::input_device같은것에 접근하게 되면
미래에 타입을 확장 혹은 수정하기 쉽지 않을거임
혼자개발할거면 좆도상관안해도 됌
인터페이스 귀찮으면 virtual 떡칠해서 애매할때마다 필요한 부분 재정의 하는 신종 클래스 만들기 ㅋㅋ 그리고 그 신종클래스에서 virtual 함수 추가해서 새로운 기능 추가하고 또 그 클래스를 상속받아서 재정의 하고 또 기능 추가하고 상속하고 재정의 하고... 자체 난독화 완료