OOP 상속 vs 조합 Composition

[@핑크픙]

오랜만에 또 이런 주제를 다루시게 되었군요.. 예전 영상도 정말 도움이 많이 되었습니다! Is A 관계도 아닌데 상속해서 쓸모없는 메소드를 내려 받아서 생기는 깨지기 쉬운 기반 클래스 문제 합성으로 해결하기부터.. 인터페이스를 써야하는 이유를 정말 명확히 알게 되었었습니다. 특히 OOP 덕후라는 그사람의 썰은 재미있게 들었어요 ㅋㅋㅋ 가물가물했었는데 이번 영상으로 복습해야겠군요 감사합니다!

[@Users-k1f]

와.. 스프링 관련 모듈 뜯어보면서 이런 구조가 너무 많아서 해석하기 힘들었는데 설명 해주시는게 딱 경험했던 부분이네요..

[@코드없는프로그래밍]

스프링은 아주 많은 회사,사용자가 있고, document가 잘 되어있기때문에 소스코드를 뜯어 볼일이 없습니다. 하지만 사내 code가 이런식이라면..퇴사마렵죠.

[@minsukim8106]

너무 유익합니다 교수님

[@낙타-p3x]

오 요즘 고민중인 주제였는데 잘보겠습니다!

[@hyeonsu-hl2ff]

변화가 자주 일어나는 엔터프라이즈 레벨의 백엔드 서비스에서는 상속을 쓸 경우가 거의 없겠네요. 쓰더라도 변화가 거의 일어나지 않을 부분 한정에 is-a 관계가 맺어진 클래스들 끼리만.

[@eezz_]

현업에서 트레이드오프 무시하고 상속 찬양하시는 분들은 아직도 있어요 ㅎㅎ 저는 LSP 원칙, self-use 문제, 수준별 개발 분리 등 언급은 계속 해주고 있습니다. 다른 클래스라도 상속이 허용되니, 결합이라는 이름도 되는군요 ㅎㅎ, 오랜만의 영상 감사합니다.

[@Grujam92]

아 마지막에 게임엔진을 언급하시네요. 어쩐지 다른분야 할땐 저도 컴포지션을 주로 쓰는데, 그래픽스 프로그래밍 할때는 상속이 아주 요긴하게 쓰이더라구요.

[@othniel0000]

결국 무엇을 만들것인가인데요. 대부분 한국에서 만드는 소프트웨어는 (거의없죠) 유통이 메인 서비스라서 솔리드 원칙 같은 것을 사용하지 않지만 순수 소프트웨어가 메인인 상품은 솔리드 원칙을 사용하지 않으면 엔트로피가 높아져서 코드 유지보수가 거의 불가능 합니다. 내가 만드는 제품에 맞는 디자인 패턴을 사용할 수 있는 기술리더가 있는 회사가 좋은 회사이겠지요. 개발자들 수준도 상향평준화가 안된다면 잘못된 상속 구조를 만들겠죠. 네이밍 부터 모두 신경써야 하고 아무나 상속구조의 코드를 작성하도록 허락을 한다는 것은 개발자 개별 역량을 중시한다는 것인데... ^^ 아무튼 좋은 제품을 만들려면 그에 맞는 디자인 패턴을 사용하면 되겠죵 ㅎㅎ 상속은 좋은거랍니다.

[@zookoong8214]

노코프님 안녕하세요? 좋은 강의 감사합니다. 제 이해가 짧은 부분에 대해서 도움 주실 수 있으실까 리플 남깁니다. :) 6:25 스냅샷 기준으로 UserHttpResponse, IngResonse 중 Response 라는 공통된 함수가 필요한 경우, Response 라는 인터페이스 클래스를 생성한다고 설명해 주셨습니다. 아울러 Response class를 Pure Virtual Class로 만든다고 하셨는데요, 그러면 결국 위 각 공통 함수 사용하려는 두 클래스가 인터페이스 클래스를 상속하는 것으로 이해하였습니다. 결국 상속을 하여 순수 가상 함수들을 composition 구조로 포함한 멤버 변수들의 함수들을 호출하게금 하는 구조라면 오히려 상속 구조가 좀 더 직관적여 보이는데 추가 설명 가능하실까욥??

[@코드없는프로그래밍]

안녕하세요. 설명이 조금 헷갈릴 수 있을것 같습니다. 제가 의도한 바는 상속에서 base class의 implementation이 숨겨진데서 만들어지는 문제입니다. 때문에 interface만 정해주고, 나머지 implementation들은 모두 그 interface들에게 온전히 맡기는게 더 이해하기 쉬운 코드를 작성할 수 있다는 뜻입니다.

[@코드없는프로그래밍]

결국은 개발자와 회사 코딩스타일에 따르게 되겠지만, 저라면 interface와 implementation은 구분하고, 상속은 사용하지 않는게 더 을것이라 생각합니다. 거기에 현대 프로그래밍 환경은 요구사항이 지속적으로 변합니다. 상속을 통해 class간의 coupling을 만들어 버리면 유연함이 없어져서 유지보수가 결국 더 힘들어집니다.

[@코드없는프로그래밍]

혹시 더 궁금한점 있으시면 댓글로 질문주세요. 감사합니다.

[@eezz_]

결국 둘 다 동작하기 때문에, 조금 애매한 경계에서 직관적인 느낌이 다를 수 있다고 생각합니다. 저는 강의에서 나온 '사용자'라는 키워드에 초점을 맞춥니다. 1. 현재 작업하는 부분이 요구사항 변화가 잦은 곳인지,, 2. '사용자'에게 제공하는 STL 같이 인터페이스 변경되지 않는 애들인지.. 그런데 2번의 경우도 우리 코드에 상속하면 self-use 버그 등 검증하는 시간도 아까우니 컴포지션 쓰는게 더 좋다고 생각합니다. 저의 경우, 회사 코드에서 다른 개발자(사용자)에게 제공하는 모듈을 만드는 경우에 주로 인터페이스 고정과 OCP 용도로 상속을 이용합니다. 환경에 따라 정답은 다를 수 있지만, 문제가 발생하는 원인은 알아야 하는 부분입니다..

[@신라면-r9b]

노콮 형님 다른 강의에서 추가 질문드렸는데 답변 부탁드려요 ㅜㅜ (cpu word 사이즈 관련) kzbin.info/www/bejne/iZPEmnSHebqcb6M 영상은 잘 보고 갑니데이~

[@코드없는프로그래밍]

안녕하세요. 답변 예전에 올렸던것 같습니다. 확인부탁드려요.