우선 편의상 약간 잘못된 설명이 있음

부모 메서드에 오버라이딩을 할 수 있고, 사실 차라는 걸 규정하면 스포츠카, 트럭 이런식으로 바꾸지만 편의상 상속의 범위를

차의 모양새로 좁혀서 생각하자





이렇게 차가 있다 하자


이건 차의 구체적인 모양을 적당히 그린


차라는 걸 추상화한거


일단 이걸 차 틀이라고 하자.


자 여기에 이제 구체적인 구현을 하자




차에 창문을 달아주고, 바퀴 모양에서도 구체적으로 구현함


이걸 보통은 상속이라고 함.


상속은 이런형식으로 특정틀이 강제되있을때 세부구현이 편하다는 장점이 있지만


당연히 이 처음에 차 틀의 모양에서 바꾸기가 힘듬


즉 is-a 관계라는것


이 차 틀이라는 것은 상속받는 것임. 즉 이 모양새는 바꿀 수가 없다 이거임(오버라이딩해서 부모 매서드를 재정의 할 수 있지만 이건 설명상 편의로 해둠)


이게 상속임. 즉 '차 틀'이라는 모양새내에서 세부적으로 구현할 수 있지만 대체로 차틀내에서 강제되는게 상속임


즉 처음에 정해진 틀 내에서만 바꿀 수 있기때문에  커스터마이징 하기가 상당히 어려움


그럼 컴포지션 즉 조합은 무엇인가





요렇게 차틀이 있지만, 창틀이랑 모양새는 바뀔 수 있고 자동 차 바퀴도 여러개 있겠지?


일단 차 틀에 대해서 바퀴랑 창의 모양새를 좀 더 자유롭게 하고 싶어


즉 has-a 관계는 무엇이냐


차 틀은 차지하고


자동차의 바퀴와 창은 모양이 계속 바껴야겠지? 차 프레임은 내버려두고





이런식으로 왼쪽 큰 바퀴와 오른쪽 작은 바퀴를 만들어두고 필요할때 끼워두는 형식으로 하는게 


컴포지션임



즉 상속은 정적인 분류 체계 -> 부모 틀을 기반으로 하는 강제적 구조, 하지만 차와 바퀴를 반드시 결합해야하는 강제적성이 있어서 강한 결합 되있다고 함


조합은 동적인 부품 조립 -> 부품을 끼워 맞추는 방식으로 유연하게 조합-> 차와 바퀴의 조합에 대해서 강제성이 덜해서 약한 결합 되있다고함


최근의 프로그래밍 기조는 동적 부품 조립으로 넘어가서 


컴포지션 쓰라고 하는거


컴포지션은 상속보다 유연하지만 관계가 약해지기때문에, 통일된 인터페이스가 강제되지 않으므로, 설계자가 규칙을 잡아야하기때문에


상속과 컴포지션 혼합하는게 프로그래머의 실력임