상속과 구현의 차이점

교육이 끝나고 혼자서 프로젝트를 진행하고 있는데 문득 드는 생각이 상속과 구현체의 차이점이 뭘까? 

라는 의문점이 들었고 책에서 본 내용을 내가 이해한바로 요약해보면 상속은 공통된 부모를 가지는것들 끼리 묶음,

구현체는 공통된 기능을 하는것들 끼리 묶음 ,concrete 메소드는 상속되고,abstract 메소드는 구현하는거고 음 ~

 

이렇게 이해를 하고 있는데 정확한건지는 모르겠다 구글링을 해봐도 대체 무슨소리인지 .. 왜이리 다들 어렵게 설명하는지.. 

 

구글링을 통해서 찾아봤다 구글구글구글 만약 구글이 없었다면 난 코딩을못,, ㅋㅋㅋㅋ

일단 찾아 보니 is- a 를 상속관계라고 하고 caon-do가 인터페이스 상속이라고 나온다 그러면 is-a, can-do 가뭐지?... 처음본다 ㅎ ㄷ ㄷ 

 

위키피디아에서 찾아보기도 해보고 구글링 통해서 알아본 바로는 

 

is-a는 추상화(형식이나 클래스와 같은)들 사이의 포함 관계를 의미하며, 한 클래스 A가 다른 클래스 B의 서브클래스(파생클래스)임을 이야기합니다. 다른 말로, 타입 A는 타입 B의 명세(specification)를 암시한다는 점에서 타입 B의 서브타입이라고도 할 수 있습니다.

 

음 그러니까 is-a 관계에 의한 상속은 ~은 ~ 이다? 

예를 들면 17살은 고등학생이다? 이런건가? 그러면 고등학생이 Base 클래스가 되고 17살이라는 클래스가

Base 클래스의 모든 멤버를 상속 받는다 이런말인거 같은데 .. 아어렵다..  ㅋㅋㅋ

그러면 반대로 고등학생은 17살이다? 18살 19 살도 고등학생이니 성립이 안되는거네 허허 음 그러니까.. 고등학생이라는 부모 클래스의 성질을 17살이라는 클래스가 물려 받는다 이렇게 해석? 하면 되나? 아 그냥 궁금증을 가지지 말껄.. 하지만 알아야 한다는걸 잘알고 있즤..

 

그리고, is-a  관계는 태생부터 무엇인가 기질을 타고 난 경우를 말합니다.  부모가 황인종이기 때문에 저도 황인종입니다.  이것은 상속 받은 유전적이며 선천적인 형질입니다. 

저는 태어나면서부터 프로그래밍을 할 줄 알았던 것은 아니지만, 지금은 할 줄 알고 있습니다.  이런 후천적인 형질은 can-do 관계라고 할 수 있습니다.
출처: https://ryulib.tistory.com/316 [류종택의 프로그래밍 강의실]

 

오? 그냥 내가 알고 있는 상속과 인터페이스 개념이구나 영어를 잘하면 반은 먹고 들어가겠다.. 

 

그러면 차이점을 알았으니 클래스 상속과 인터페이스 구현의 차이를 한번 보자구 역시나 구글은 나의 선생님이다

찾아보다가 그나마내가 이해 하기 쉬운 글을 찾았다

 

 

설계 이후부터 기반 클래스의 변화가 파생 클래스에게 그대로 이어져도 상관없을 듯 한 자연스러운 유사성이라면 이것을 유전적인 형질과 동일하게 취급할 수 있다는 뜻 입니다.  또, 다시 첨언 한다면, 설계가 튼튼해서 앞으로도 크게 문제가 없을 듯 한 것들은 상속을 이용한다고 해도 큰 문제가 없고, 오히려 상속을 사용해야 코드가 간결해지고 효율적이라는 이야기 입니다.

역시나 케바케 라는 말이구만 음 ~ 

 

처음 설계 할 때에는 전혀 고려 할 수도 없었던 변화가 생기거나 예측이 된다면, 상속보다는 인터페이스를 사용해야 하고, 이 것들은 후천적인 형질, 즉, 후천적인 문제로 간주 할 수 있다는 뜻 입니다.  

음 상속을 하면 한계점이 있으니 구현체를 이용해서 후천적인 기능을 추가한다 라는말인거 같은데 

 

상속을 받아서 따로 추가한 기능과 같은 후천적인 문제는 아무런 문제가 될 것이 없습니다.  그냥 그렇게 하면 됩니다.  문제는 이러한 것들이 중복되는 경우입니다.  즉, 복수의 객체가 자신의 종과 상관이 없는 기능이 추가되었는데, 이것이 서로 중복이 될 경우 입니다.

 

"그 기반 클래스와 부류(파생 클래스)들은 당연히 그래" 라고 할 수 있다면, 그 모든 클래스들은 같은 종이 됩니다.  그리고, 그 기반 클래스와 파생 클래스의 관계는 "Is-a"와 같은 관계에 있다고 할 수 있습니다.  동일한 종(種)으로 취급을 받는 것 입니다.  

 

"Is-a" 관계를 나타내는 것은 상속이 자연스럽습니다.

 

예를 들면, 나도 사람이고 아내도 사람입니다.  우리는 같은 종(種)입니다.  그래서, 배도 고프고, 짜증을 낼 때도 있고, 아프기도 합니다.  이런 것들은 너무나 당연한 유전적인 형질들입니다.  상속되는 것이죠.  그런데, 저는 프로그래밍을 할 수 있지만, 아내는 컴퓨터 다루는 것 자체를 어려워 합니다.  그리고, 제 동료들은 역시 프로그래밍을 잘 합니다.  이러한 형질들은 사람이니까 당연히 할 수 있는 것이 아닙니다.  획득된 형질들이며, "Can-do"로 분류 할 수 있는 것 들 입니다.

 

"Can-do" 의 특징을 같는 것들은 인터페이스 구현이 자연스럽습니다.

문제는 소프트웨어 개발의 관점에서는 경우에 따라서 유전적 형질에 대한 판단이 달라진다는 것 입니다.  만약 프로그래머가 핵심 관점이라면, 프로그래밍 능력은 유전적인 형질로 취급 될 수 있습니다.  더구나, 요구사항 변화로 인해 다양한 관점에서 접근하게 된다면, 이러한 기준이 지속적으로 흔들릴 수도 있습니다.  이처럼 현실과 코드 사이의 차이는 상당합니다.  이부분은 설계자의 재량이 필요한 부분이라고 할 수 있겠습니다.

 

음~ 즉 관점에 따라서 설계가 달라진다는 말인데 개발자의 능력이 진짜 중요하구나라는걸 느낀다

 

물론 다중상속을 통해서 해결할 수도 있습니다.  하지만, 다중상속은 단일상속에 비해서 코드를 어렵게하는 단점이 너무 뼈 아픕니다.  더구나, 다중상속을 지원하지 않는 언어가 상당히 많기 때문에 완벽한 해결책이라고 할 수 없습니다.

 

처: https://ryulib.tistory.com/76 [류종택의 프로그래밍 강의실]

 

즉 내 생각을 정리하자면

동물이라는 속성이 있는데  고양이 , 사자 , 기린 이 3가지는 동물이라는 속성을 상속 받고 사자는 띄어가고 기린은 기어간다 말그대로 기능들을 인터페이스가 하는역할인거고 음 ~~ 아직 완벽하게 이해를 한건 아니지만 어느정도 알겠다! 야호! 

개발은 할수록 뭔가 우주를 파헤쳐 보는?? ㅋㅋ 그런 기분이 든다 뭐가 계속 나와.. ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

 

블로그 글쓴이도 결론은 상황에 따라서 적절한 선택을 해야 한다고 한다 .  참으로 무책임한 말이긴 하지만, 어쩔 수 없는 현실이라고 한다

개념을 잡아가면서 코딩을 하다보니 코딩속도가  느려지고 있다..