상속쓸 빠에 클래스로 따로 묶어놓는게 맞지
그걸 왜 굳이 상속으로 씀
설계 바꾸면 인터페이스부터 클래스까지 다 바꿔야되는데
며칠안에 바꿔야 되면 바꿀 자신 있음?
그 개발하는 약간의 생산성보다 클래스 따로 빼놓아서
쓰는게 유지보수적인 측면에도 훨씬 낫다고 보는 입장인데
1. 현실 세계에서 완벽한 계획은 존재하지 않음
2. DB아키텍처도 composite 구조임
3. 상속으로 하면 설계 잘못했을 떄 interface default method 처럼 강제성을 줬는데, 이걸 일부 클래스만 적용해야되거나 다른 인터페이스/ 클래스를 만들어야 하는 불상사가 발생
이래도 인터페이스 쓰는 이유가 composite를 썼을 때보다 프리벤티지가 있음?
클래스를 따로 묶는다는게 무슨말임??? - dc App
composite 모름?
클래스 단에서 DI처럼 의존성 주입하는 식으로 집어넣기 ㅇㅅㅇ
맞는말임 - dc App
컴포지션 쓰는게 맞음 - dc App
인터페이스랑 상속은 상관없는데 ㅇㅅㅇ;; composite 해도 interface 베이스로 여러 context 두고 resolver 두는 아키텍처로 구성함
그러면 인터페이스 default method 안쓰고 추상화된 함수만 지원하는 형태로 씀?
그리고, 그런 경우에도 해당 클래스에 필요없는 메소드가 강제될 수 있는데 그러면 인터페이스는 따로 빼 놓아서 씀?
인터페이스를 잘개 쪼개는편. 단순 Service 이런건 인터페이스 안만듦. 실제로 회사 코드에 ~~ Service 이런건 없기도 하고
이해를 잘 못하겠음 하나의 함수에 하나의 인터페이스를 쓸 로직이면 그냥 하나의 함수를 다는 코드가 낫지 않음?
왜냐면 각각의 기능체에 대해 이미 로직을 구현화하는 시점부터 로직 자체에 차이점이 발생한다는 말인데, 거기서 하나의 이름을 구현체에서 구체화한다는 의미가 오히려 스스로를 망치는 것 같은 느낌이 옮
두~세 개 n개에 달면 마찬가지로 함수를 많이 달면 많이 달수록 위험도가 커짐 하나의 인터페이스가 내포하는 로직이 많아져서.. 물론 설계를 바로 바로 한다면 속도적인 측면은 있겠지만, 현실적으로..ㅇㅅㅇ..
구현체가 여러개니까ㅇㅅㅇ.. 예를들어 A가 B에게 상품을 선물할 때 잔액이 충분해야하고, 재고가 있어야 하고, 받는 사람과 보내는 사람 모두 본인인증이 되어 있어야 한다는 비즈니스 로직이 있다면, 그리고 저것들을 체크하는 것들이 다 다른 서버라면 동일하게 Validation Context를 지닌 여러개의 로직을 짜야하는데.. 이걸 하나하나 Di 받아서 할바엔 인터페이스로 뽑고 List 타입으로 Di 받는게 좋지 ㅇㅅㅇ;;
암튼 내가 말한건 '상속'이 아니라 인터페이스를 사용하는 이유임ㅇㅅㅇ;; 나도 상속은 안씀
그건 님 말이 맞음 속도 적인 측면은 인터페이스가 좋음 ㅇㅅㅇ
엔터프라이즈 어플리케이션으로 갈수록 세부 구현은 조금씩 달라도 전체 컨트롤 플로우는 비슷하게 가져가는 로직이 많아서 상속으로 갈 수 밖에 없음 그리고 메타프로그래밍이 가능한 언어의 경우 composite는 내부 구조 예측이 어려운 반면 상속과 generic으로 다져놓은 클래스 뭉치들은 메타 분석을 통해 build-time, run-time 모두 제어가 쉽기 때문에 규모가 커질수록 상속이 가지는 이점이 많음
composite도 클래스에서 내부 구체화해서 로직 다룰 수 있는데 그렇게 생각한 이유가 멀까 궁금하네. 이미 상속된 코드가 많으면 그럴 수 밖에 없는건 맞다고 생각함
composite만으로는 외부 인터페이스 통일이 안되니까, 평행구조 로직이 많을수록 상속을 통해 구현하고, 외부에선 일관된 인터페이스로 제어하는게 더 쉽기 때문임. composite는 수직적인 로직이 많을수록 더 유용함 왜냐면 상속은 is-a관계고 composite는 has-a관계라서 모듈상의 순서가 실제 로직상의 순서로 일치시키는게 직관적으로 이해되기 때문
예를들어 서버로부터 명령을 받아 서로 다른 기능을 처리하는 class A, B가 있다고 치자 A는 sync하게 바로 리턴 가능한 단순 로직인 반면, B는 thread-pool에서 스레드를 포크하거나 해서 언제 끝날지도, 끝날 수 있을지도 모르는 로직을 가지고 있다고 쳐 근데 A,B 모두 서버에서 온 커맨드를 복호화하고, arg를 검증하고(전처리), 작업 끝날시 걸린 시간을 체크하고, 결과를 서버에 리포트하며, 실패시 failover까지 해야 된다(후처리)고 가정하자 당연히 B의 세부로직은 서너단계의 composite로 구성된 클래스들을 이용하는게 맞음. 심지어 스레드풀같은 경우엔 더 상위 class를 참조해야 할지도 모르지, 반면에 전/후처리 기능은 상속을 통해 구현하는게 당연히 훨씬 더 나음
그래야 복호화 로직을 일괄적으로 수행하거나, validator를 DI로 삽입하는게 편하기 때문
그리고 고수준의 개발을 겪다보면 runtime meta programming이 아니라 아직 빌드도 안된 코드로 source 분석 전처리기 같은걸 구현해야 할 수도 있음. 이럴땐 composite만으로 구성된 모듈들은 거의 불가능하지, 왜냐면 내부 구성에 대한 예측이 안되니까. 하지만 상속과 generic으로 구성한 모듈들은 이미 외부 인터페이스 규격이 결정되어 있으니까 이러한 전처리기를 만들때 매우 편리하다.
형 AA야?? - dc App
전체적으로 비슷한 말인듯 평행구조(동일한 구조)만을 취하면 상속이나 인터페이스가 낫다 테스트코드 작성면이나 코드 분석면에서. 코드 작성 면에서. 반면 코드가 바뀌게 되거나 구현체의 기능이 비슷한데 조금씩 다른게 존재한다면 이게 꽝이 된다는게 결론인듯
아니 현재 개발 25년차 리드 프로그래머임
ㄴㄴ잘 이해했음
후자 얘기가 더 나왔네 좀 더 볼게요 ㄱㅅㄱㅅ
리스펙트합니다 - dc App
그래서 메타 프로그래밍이라고 표현하셨구나.. 무슨 말씀이신지 이해됨 일관성을 보장하는 간단한 메소드는 인터페이스. 단계로 구성되거나 구현체로직이 많이 나타날 경우에는 composite 무슨 말씀으로 얘기하셨는지 스타링크님이랑 다른 관점에서 비슷한 얘기를 하신거구나 이해됨.. ㄱㅅㄱㅅ
상속 없으면 ostream에 출력 << 연산자 오버로딩 어케 구현함...
코드에서 그렇게 쓰라고 제공하는건 해야지 ㅇㅅㅇ
프리벤티지가 어떤거임? ㅇㅅㅇ ㅡ wounded healer
오랜만에 잼는글