[{"data":1,"prerenderedAt":148},["ShallowReactive",2],{"post-document:\u002Fbackend\u002Fjava\u002Foop\u002F2026\u002F08\u002F12\u002FSOLID\u002F":3},{"id":4,"title":5,"body":6,"categories":132,"date":136,"description":22,"extension":137,"image":138,"key_concepts":138,"last_modified_at":138,"legacyPath":139,"meta":140,"navigation":142,"part":138,"path":143,"published":142,"robots":138,"seo":144,"series":138,"stem":145,"strengths":138,"summary":138,"tags":146,"tradeoffs":138,"__hash__":147},"posts\u002Fposts\u002FBackend\u002FJAVA\u002Foop\u002FSOLID.md","SOLID",{"type":7,"value":8,"toc":128},"minimark",[9,13,20,23,42,45,49],[10,11,5],"h1",{"id":12},"solid",[14,15,16],"blockquote",{},[17,18,19],"p",{},"유지보수성, 확장성, 재사용성을 높이고 결합도 (Coupling)울 낮추기 위한 OOP의 5대 설계원칙.\nClean Architecture (지속가능한 튼튼한 소프트웨어 구조)를 구성하기 위한 핵심적인 기초 원리",[17,21,22],{},"SOLID 원칙을 큰 그림에서 바라보면",[24,25,26,30,33,36,39],"ul",{},[27,28,29],"li",{},"객체 간의 결합도를 낮추고, 객체 내 응집도를 높이는 원칙",[27,31,32],{},"인터페이스와 추상화를 적극적으로 수용 (What(사용)과 How(구현)를 분리)",[27,34,35],{},"변경이 필요할 때 기존 코드 수정 없이 확장이 설계하도록 설계 (상속\u002F확장)",[27,37,38],{},"고드 유지보수성과 테스트 용이성을 향상",[27,40,41],{},"Clean Architecture는 관심사 분리(separation of Concerns)를 기반으로 애플리케이션을 계층 별로 나누고\n각 계층이 자신의 역할에만 집중하도록 설계하는 아키텍처.\n비즈니스 규칙 과 기술 세부적 공통 사항을 분리",[17,43,44],{},"개념을 잘 익히고 개념을 AI에 잘 집어넣자.",[10,46,48],{"id":47},"solid-원칙","SOLID 원칙",[24,50,51,54,57,76,87,98,114],{},[27,52,53],{},"객체지향에서 시작되었지만, 객체뿐만 아니라 마이크로서비스와 API Level에 SOLID 원칙을 고려",[27,55,56],{},"이를 통해 유지보수성을 개선할 수 있다.",[27,58,59,60],{},"S : Single Responsibility Principle",[24,61,62],{},[27,63,64,65],{},"한 클래스는 하나의 책임만 가져야 한다. 구현자 관점\n",[24,66,67,70,73],{},[27,68,69],{},"한 클래스가 변경되어야 할 이유는 오직 하나여야 함",[27,71,72],{},"한 클래스가 여러 기능을 담당하면, 한 기능의 변경이 다른 기능에 부정적인 영향을 줄 수 있음",[27,74,75],{},"적용 예시 : Spring Boot Controller, Service, Respositoty",[27,77,78,79],{},"O : Open\u002FClosed Priciple\n행위의 본질을 '추상화(인터페이스, 규격)'하고 구체적인 세부 기능은 '플러그인' 형태로 갈아 끼울 수 있게 만드는 것",[24,80,81,84],{},[27,82,83],{},"기존 코드는 변경하지 않고(공통 흐름), 새로운 기능 (세부 구현)을 추가할 수 있어야 한다.",[27,85,86],{},"인터페이스, 추상 클래스, 다형성을 활용한 구현",[27,88,89,90],{},"L : Liskov Substitution Principle\n자식 클래스는 언제나 부모 클래스의 역할을 대체해야 한다",[24,91,92,95],{},[27,93,94],{},"자식 클래스는 부모 클래스가 정의한 계약을 위반하지 말아야 한다",[27,96,97],{},"부모 클래스의 행동(method)을 호출하는 코드에서 자식 클래스로 대체하더라도 정상적으로 동작",[27,99,100,101],{},"I : Interface Segregation Principle",[24,102,103],{},[27,104,105,106],{},"클라이언트는 자신이 사용하지 않는 메서드에 의존하지 말아야 한다 사용자\u002F소비자 관점\n",[24,107,108,111],{},[27,109,110],{},"하나의 범용적인 인터페이스보다는 여러 개의 구체적인 인터페이스를 만들어야 함",[27,112,113],{},"한개의 인터페이스에 너무 많은 기능을 담고 있으면 이를 구현한 클래스는 불필요한 메서드를 강제로 구현",[27,115,116,117],{},"D : Dependency Inversion Principle\n고수준 모듈은 저수준 모듈에 의존하면, 둘 다 추상화에 의존해야 한다.\n추상화는 구체적인 것에 의존해서는 안되고, 구체적인 것이 추상화에 의존해야 한다.",[24,118,119,122,125],{},[27,120,121],{},"고수준 모듈 : 비즈니스 정책, 흐름 (Process, Service)",[27,123,124],{},"저수준 모듈 : 세부 구현, 기술, 라이브러리",[27,126,127],{},"추상화 : interface, abstract class",{"title":129,"searchDepth":130,"depth":130,"links":131},"",2,[],[133,134,135],"Backend","JAVA","oop","2026-08-12 17:47:59 +0900","md",null,"\u002Fbackend\u002Fjava\u002Foop\u002F2026\u002F08\u002F12\u002FSOLID\u002F",{"layout":141},"post",true,"\u002Fposts\u002Fbackend\u002Fjava\u002Foop\u002Fsolid",{"title":5,"description":22},"posts\u002FBackend\u002FJAVA\u002Foop\u002FSOLID",[],"UCiJ4O_L0luksQhP9qwXTXEXYxMxsf7TOktoNG-2nbI",1788744785178]