[본캠프] 13일차

윤영범·2026년 3월 26일

객체지향설계 SOLID 의 원칙

이전에 개발자들은 수많은경험들을 통해 프로젝트가 망가져가면서 절차지향적인 코드를 완성했었다

절차지향코드?

"무엇을(기능)" 중심으로 코드가 어떻게 작동할지 순서에 집중한다 명령을 순차적으로 시작하는방식

그치만 이러한 코드에 문제는 프로젝트가 커질수록 유지보수가 어려워지고 코드의 재사용성이 낮아지면서 디버깅에 오류를 가지는 스파게티 코드가 되버린다

  • 수정을 하나하려고하면 여러파일을 전부고쳐야하는 상황이생겨버리고 ( Shotgun Surgery)
  • 한 부분은 수정코드를 건들이면 다른부분까지 줄줄이 건들여야한다 (Ripple Effect)

우리는 이러한 코드들을
높은 결합도(High Coupling)와 낮은 응집도(Low Cohesion)을 가진 코드라고한다

우리는 유지보수가 쉽고 확정성이 뛰어나면서 이해하기 쉬운코드를 만들어야한다
결합도를 낮추고 응집도를높혀 견고한 소프트웨어의 구조를 설계해야한다
그 구조에 맞는 설계를 하기위한 처방이 SOLID 의 5가지 원칙이다

즉 SOLID 원칙은 규칙이 아니라, 오랫동안 수많은 프로젝트가 망가지며 얻은 고통의산물이다

S : Single Responsibility

클래스는 변경이유가 하나뿐이어야한다

하나의 클래스는 하나의 역활만 가져야한다 그 책임을 침범하면안된다
이번에 실습하게된 커머스과제를 통해 예를 들어보면

Product.java 는 개별 상품만을 관리하는 클래스로 정의해야하는데
상품목록관리 , 출력까지 전부 하고있다 이럴경우 수정해야할때 여러곳을 보수해야하는
SRP 위반사례이다

O : Open / Closed

확장엔 열려있고, 수정엔 닫혀있어야한다

  • 추상클래스 , 인터페이스가 OCP 의 핵심도구
    새로운 기능을 추가할때, 기존코드를 수정하는게 아니라, 새 코드를 추가한다
    if,switch문을 사용할때 항상 OCP를 위반하는지 확인해야한다

    새로운 연산을 추가할때 기존코드를 수정하는것이아닌
    MUL("*") {
    public int apply(int a, int b) { return a
    b; }
    }
    새로운 객체생성을 추가하면서 처리할수있다

그러나 OCP 관점에서는 기능을 추가하게되면 클래스가 결국생겨나는거니,
main을 계속 수정해야 하며 객체를 인스턴트화 해줘야하는데

그걸 도와주는게 앞으로 배울 Spring 이라고한다
DI (의존성 주입), 제어의 역전(IOC)

L : Liskov Substitution

자식클래스는 부모를 완전히 대체할수있어야한다

쉽게말하면 상속했으면,부모클래스 대신써도 똑같이 동작해야한다 다형성을 지원하기위한 원칙

잘못된설계 X

올바른 설계 O

출저:https://notavoid.tistory.com/326

I : Interface Segregation

쓰지않는 메서드에 의존하면 안된다

인터페이스 분리 원칙(ISP)은 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙입니다. 이는 인터페이스를 작고 구체적으로 설계하여, 클라이언트가 필요하지 않은 기능에 의존하지 않도록 하는 것을 목표로 합니다.

예를 들어, 프린터 인터페이스를 복합적으로 설계하는 대신, 스캔, 출력, 복사 기능을 각각의 인터페이스로 분리하여 필요에 따라 구현할 수 있습니다.

기능 단위로 인터페이스를 잘게 쪼개어(Segregation), 각 클라이언트가 필요한 메서드만 가지는 인터페이스를 제공해야 합니다.

올바른 인터페이스 분리 예시

D : Dependency Inversion

구체 구현이 아닌 추상화에 의존해야한다

객체 생성 책임을 밖으로 빼는 것
즉 구체적인 클래스보다 상위클래스,인터페잇,추상클래스와 같이 변하지 않을 가능성이 높은 클래스와 관계를 맺으라는 것

출저 : https://velog.io/@_bono12/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84-%EC%9B%90%EC%B9%99-SOLID

마무리하며

원칙간의 연결고리

5개의 원칙은 독립적인 규칙이 아니다

업로드중..

  • OCP는 DIP 없이 지키기 어렵다
    • 확장에 열려있으려면 추상화에 의존해야 한다
  • LSP를 어기면 OCP도 무너진다
    • instanceof 분기가 생기고, 새 자식 추가마다 기존 코드를 수정해야 한다
  • ISP와 SRP는 함께 작동한다
    • 인터페이스에도 단일 책임이 적용된다
  • DIP는 모든 원칙의 토대
    • 추상화에 의존해야 나머지 원칙을 실천할 수 있다

항상 코드 설계를 할때 5가지 원칙을 생각하며 대입해보자

0개의 댓글