리스코프 치환원칙이 어떤건지에 대해 잘 설명해주셔서 감사합니다. 처음 SOLID 원칙을 공부할때 가장 이해가 되지 않았던 부분이 리스코프 치환원칙이었는데 리스코프 치환원칙을 검색해서 찾아보아도 어떤 말인지 와닿지 않더라구요. 부끄럽게도 SOLID 원칙의 L부분은 그냥 버려야 겠다 생각하고 살아왔는데 덕분에 손쉽게 알게되었습니다
default 메서드의 무분별한 사용은 ISP를 위반할 수 있습니다. 이를 좀 더 구체적으로 설명하면: 불필요한 메서드 노출 인터페이스에 default 메서드를 추가하면, 모든 구현체가 이를 보게 됩니다. 그런데 특정 클라이언트는 해당 메서드를 사용하지 않음에도 불구하고 그 메서드가 인터페이스에 포함되어 버립니다. 예: interface A에 default void methodX()가 추가되었을 때, methodX()를 필요로 하지 않는 구현체들도 이 메서드를 보게 되어 인터페이스 분리 원칙을 위반합니다. 클라이언트 의존성 증가 클라이언트는 원하지 않는 기능에 의존하게 됩니다. 만약 default 메서드에 구현이 되어 있다 하더라도, 이는 클라이언트 코드의 설계 의존도를 증가시킬 수 있습니다. 유지 보수의 어려움 default 메서드의 도입은 인터페이스의 기존 기능을 확장하는 데 유용하지만, 이는 쉽게 새로운 메서드를 추가하도록 유도합니다. 이렇게 되면 점차 인터페이스가 비대해질 수 있습니다. 결과적으로 ISP를 위반하는 "큰 인터페이스"가 될 가능성이 커집니다.
유익한 내용이네요. 약간 곁가지 이야기이지만 코드 수정할 때도 비슷한 방식이 필요하더라고요. 코드를 고치다보면 원래 고치려던 부분외에도 다른 고칠 부분도 여기저기 많이 보이게 되는데 그런것들도 손대기 시작하면 코드가 산으로 가더라고요. 고칠덴 아무리 옆에 잘못된 다른 부분이 보이더라도 메모만 해 놓고 원래 고치려던 부분만 고쳐서 테스트해야 되겠더라고요. Single Responsibility와 약간 유사한 개념이지 아닐까요?
🎫 얄코 강의 선착순 반값쿠폰 (매주 갱신)
bit.ly/yalco-fcfs-coupon
예제코드 확인 : yalco.notion.site/SOLID-Principles-581f158bec174916b5b41df3dd72d250?pvs=4
얄코 강좌들 보기:
www.yalco.kr/#lectures
얄코 책 보기:
www.yalco.kr/#books
예제들이 아주 훌륭하네요
감사합니다!
예제들로 쉽게 이해할 수 있었습니다. 자세한 설명 감사합니다!
도움되어드려 기쁩니다! 시청해주셔서 감사합니다~!
정말 잘 설명해주신거 같습니다. 감샇바니다.
감사합니다!
정말 감사합니다!
감사합니다!
리스코프 치환원칙이 어떤건지에 대해 잘 설명해주셔서 감사합니다. 처음 SOLID 원칙을 공부할때 가장 이해가 되지 않았던 부분이 리스코프 치환원칙이었는데 리스코프 치환원칙을 검색해서 찾아보아도 어떤 말인지 와닿지 않더라구요. 부끄럽게도 SOLID 원칙의 L부분은 그냥 버려야 겠다 생각하고 살아왔는데 덕분에 손쉽게 알게되었습니다
유익한 내용 감사합니다
재밌어요 감사합니다
감사합니다!
isp 법칙에서 인터페이스에 default가 사용될 시 사용위반이 어떻게 되는지 궁금합니다
default 메서드의 무분별한 사용은 ISP를 위반할 수 있습니다. 이를 좀 더 구체적으로 설명하면:
불필요한 메서드 노출
인터페이스에 default 메서드를 추가하면, 모든 구현체가 이를 보게 됩니다. 그런데 특정 클라이언트는 해당 메서드를 사용하지 않음에도 불구하고 그 메서드가 인터페이스에 포함되어 버립니다.
예: interface A에 default void methodX()가 추가되었을 때, methodX()를 필요로 하지 않는 구현체들도 이 메서드를 보게 되어 인터페이스 분리 원칙을 위반합니다.
클라이언트 의존성 증가
클라이언트는 원하지 않는 기능에 의존하게 됩니다. 만약 default 메서드에 구현이 되어 있다 하더라도, 이는 클라이언트 코드의 설계 의존도를 증가시킬 수 있습니다.
유지 보수의 어려움
default 메서드의 도입은 인터페이스의 기존 기능을 확장하는 데 유용하지만, 이는 쉽게 새로운 메서드를 추가하도록 유도합니다. 이렇게 되면 점차 인터페이스가 비대해질 수 있습니다. 결과적으로 ISP를 위반하는 "큰 인터페이스"가 될 가능성이 커집니다.
DRY 원칙도 있어요
네, KISS, YAGNI, DRY는 꼭 객체지향 뿐 아니라 폭넓은 분야의 프로그래밍에 적용 가능합니다.
하나의 클래스에 기능을 몰아넣지 말고 기능을 분활하라 이런건가 🤔
분활x 분할o
유익한 내용이네요. 약간 곁가지 이야기이지만 코드 수정할 때도 비슷한 방식이 필요하더라고요. 코드를 고치다보면 원래 고치려던 부분외에도 다른 고칠 부분도 여기저기 많이 보이게 되는데 그런것들도 손대기 시작하면 코드가 산으로 가더라고요. 고칠덴 아무리 옆에 잘못된 다른 부분이 보이더라도 메모만 해 놓고 원래 고치려던 부분만 고쳐서 테스트해야 되겠더라고요. Single Responsibility와 약간 유사한 개념이지 아닐까요?
말씀주신대로 코드 리펙토링에도 적용될 수 있는 개념입니다. 때문에 애초에 코드를 설계할 때부터 이런 부분들을 유념하지 않으면 이후에 고생하게 되더군요 😰
목소리를 AI?로 학습시킨건가요,,,?
이건 제가 녹음한건데요;;