이거 걍 하위 클래스로 하나하나 접근하지 말고 인터페이스 쓰셈 이런 말 아님?
[%] 의존관계 역전 원리
익명(119.200)
2022-05-20 17:18
추천 0
댓글 23
다른 게시글
-
땔감이 잡으면 타스도 의미없긴해 [5][%] 익명(118.235) | 22.05.20추천 2
-
자바스크립트 생태계가 복잡하긴해 [5][%] black7375(58.227) | 22.05.20추천 3
-
새로운 언어가 계속 생기는 이유가 있네 [1][%] 익명(121.134) | 22.05.20추천 0
-
인성나빠도 능력좋은 놈이 낫단건 찐myth다 [8][%] 익명(6hyguathltgk) | 22.05.20추천 4
-
WebGL Camera 관련 질문 하나 해도 됨? [7][질문] 익명(203.252) | 22.05.20추천 0
-
《서버 개발자를 위한 지침서》 [4][%] ryu(163.239) | 22.05.20추천 0
-
방금 알아낸 디시 꼼?수 [15][%] 익명(210.222) | 22.05.20추천 0
-
러스트와 js가 최고지 [3][%] ryu(ashrad) | 22.05.20추천 0
-
나는 정적 타입 언어가 좋아 [3][%] 익명(211.208) | 22.05.20추천 2
-
첫 입사 선배가 중요한 이유 [6][%] ryu(163.239) | 22.05.20추천 4
설명이 부족함. 간단히 얘기하면 클래스 말고 인터페이스에 의존하라는 얘기임. 인터페이스에 의존하게 하면, 그 인터페이스를 구현한 클래스면 뭐든 갈아끼울 수 있음. - dc App
그니까 그 말 한 거임
그냥 추상화하는 방법을 고급져보이게 쓴거임 패션 개발자 새끼들 입발린 말임
걍 SOLID 라임 끼워 맞춘 것 같은데 ㅅㅂㅋㅋ
위에놈들 다 뭔소리하는거임.. 인터페이스랑 의존관계역전이랑 아무 상관도 없음 isp얘기면 모를까
그냥 인터페이스 쓰기만한다고 호출자입장에서 클래스 모르고 쓸수있냐?
인터페이스만 써서 구현부와 선언부 완전 분리한 예제들고 오면 인정해준다
저는 님 말을 이해못하겠음. 스프링의 DI가 DIP예시 아님? - dc App
인터페이스만 달랑 쓰면 알아서 빈주입해주냐고.. 스프링이 di해주는거지 그게 의존관계 역전인거고. 프레임워크없이 인터페이스쓴다고 역전이 되겟습니까.
글고 스프링 빈주입은 인터페이스 없이 써도 상속으로 빈주입해주니까 인터페이스 굳이 안써도 될거고.
결국 의존관계면은 인스턴스가 필요하고, 그건 스프링이 대신 해준다는거죠? 그 과정에서 인터페이스는 타입어노테이션 역할하는거고?? - dc App
인스턴스 얘기가 없어서 이해하는데 시간 좀 걸렸음 ㅎㅎ 설명ㄱㅅㄱㅅ - dc App
isp -> 인터페이스를 사용하세요. (사용하면 결합도가 낮아지고 재사용성이 올라가며.. 기타등등) dip -> 호출자는 잘 변경이 일어나는 호출객체에 의존성을 가지면 안됩니다. -> oop세계에서 모든 호출자는 호출하는 객체에 의존성을 가지게 됨. 당연함. 현실세계에서 김모씨가 자기가 스스로 못하는 인쇄라는 작업을 프린터에게 "의존"해서 처리하고 있는 것과 동일함. 여기까진 문제가 없음. 그런데 만약 오늘은 삼성프린터였는데 내일은 써본적도 없는 LG프린터기로 바뀌면 어떻게 될까? 대부분의 프린터회사는 ux 표준이란게 있어서 잘몰라도 쓰게 해준다지만.. 그딴게없어서 인쇄할때마다 프린터 사용법을 새로 배워야한다면? 빡치겠지. 즉 호출자가 호출하는 객체에 휘둘리게 됨. 이런걸 하지말라는거(isp와도 관련이 있는 이야기.). 근데 그럼 코드로는 어케 그렇게 해줄수있는데? 자바라면 "사용하려는객체 a" = new 사용하려는객체() 라고 할텐데 이걸 인터페
이스로 변경해서 "사용하려는객체인터페이스 a" 타입으로 변경한다해도, 초기화는 결국 구현체 클래스로 해야지. 그렇다면 호출하는 객체는 구현체 클래스를 실제로 알고 있게 되는거고, 이걸 의존관계가 양방향이 된거임. (구현체 클래스가 이름이 변경되던지 하면 호출하는 객체에도 변경이 일어나게 됨) 의존관계역전은 이 의존관계를 양방향에서 단방향으로 바꾸는 것에 의의가 있고 스프링은 이 목표를 자체 di 기능으로 달성하고 있는거임. 클래스던 인터페이스던 호출하는 객체는 자기가 뭘 사용하는지도 모르게끔 해주니까.
하나만 알고 둘은 몰랐었네. 자세한 설명 고맙슴당
그니까 사용자가 a고 프린터가 b고 프린터 내부 부품이 C라 했을때. a는 b에 의존하지만 a가 c에는 의존하지 않게 하는게 의존 역전 아님? c를 구현체라 했을때 b의 인터페이스를 가지고 의존을 해서 구현을 하고 a역시 b에만 의존을 하게 해서 a랑 c의 의존을 제거하는게 내가 이해하고 있었는 내용이였는데 - dc App
그건 lsp에 가까운 것 같음. 그리고 프린터가 인터페이스가 내부 부품이 구현이라는건 틀린 비유임. 프린터라는 '추상적인'개념이 인터페이스고, 삼성 프린터, lg프린터를 구현이라 보는게 더 맞는 비유임. - dc App
그 ABC는 SOLID보단 디미터 원칙같음
이런건 걍 UML 그려서 화살표 방향만 얘기하면 엄청 쉬운데 글로 풀어적으려면 까다로운듯
코드 임포트 하는 방향이 자주 바뀌는 구현을 직접 쓰는게 아니라 인터페이스를 임포트 해놓고 구현은 다른곳에서 해서 연결하면 임포트 하는 방향이 반대가 되는데 이걸로 코드 정리하자는거임
위에서 한 얘기도 같은얘기임 스프링같이 DI 프레임워크 있으면 이제 구현 연결하는거 조차 내가 신경 안쓰는거고
아... 디미터 원칙이란게 있었네. 몰랐음. 앞서 lsp같다고 한건 B와 C가 is-a 관계가 아니고 has-a 관계기 때문에, 치환될 수 없다는 맥락에서 한 말이었음. 혼동을 줄 수 있으므로 정정함. lsp랑 별개임.
남 지적할꺼면 본인부터가 좀 제대로 알고 지적하는게 맞지 않을까? isp dip 왜 다 틀리게 설명함? 나중에라도 이글 찾아보는 사람은 이인간 틀린설명 말고 로버트마틴이 직접 solid 설명한거 찾아보는거 추천함 - dc App