SOLID 원칙(좋은 객체 지향 설계)과 Spring의 필요성

SOLID는 클린 코드로 유명한 로버트 마틴이 제안한 객체 지향 프로그래밍 및 설계의 다섯 가지 핵심 원칙이다.

1. 단일 책임 원칙 (Single Responsibility Principle, SRP)

"한 클래스는 오직 하나의 책임만 가져야 한다"는 것이 SRP의 핵심이다. 여기서 '책임'이란 무엇일까?

주문 시스템에서 다음과 같은 클래스가 있다고 가정해보자.

// SRP를 위반하는 예시
class Order {
    public void calculateTotalPrice() { ... }
    public void printOrder() { ... }
    public void saveToDatabase() { ... }
}

// SRP를 준수하는 예시
class Order {
    public void calculateTotalPrice() { ... }
}

class OrderPrinter {
    public void printOrder(Order order) { ... }
}

class OrderRepository {
    public void saveOrder(Order order) { ... }
}

 

첫 번째 예시는 주문 계산, 출력, 저장이라는 세 가지 책임을 모두 가지고 있어 SRP를 위반한다.

반면, 두 번째 예시는 각 클래스가 하나의 책임만 가지도록 분리되어 있는 것을 알 수 있다.

 

적용 이유 : 코드의 이해와 유지보수를 쉽게 하고, 특정 책임 변경이 다른 책임에 영향을 미치지 않도록 하기 위함.

실제 사용 : 

• MVC 패턴에서 Controller는 요청 처리, Service는 비지니스 로직, Repository는 데이터 접근으로 역할 분리
• 스프링 빈으로 등록하여 관심사를 분리

2. 개방-폐쇄 원칙 (Open/Closed Principle, OCP)

"소프트웨어 요소는 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다"는 원칙으로 추상화와 다형성을 통해 구현할 수 있다.

// OCP를 위반하는 예시
class PaymentProcessor {
    public void processPayment(String type) {
        if (type.equals("CREDIT")) {
            processCreditPayment();
        } else if (type.equals("DEBIT")) {
            processDebitPayment();
        }
        // 새로운 결제 방식을 추가할 때마다 코드 수정 필요
    }
}

// OCP를 준수하는 예시
interface PaymentMethod {
    void processPayment();
}

class CreditPayment implements PaymentMethod {
    public void processPayment() { ... }
}

class DebitPayment implements PaymentMethod {
    public void processPayment() { ... }
}

// 새로운 결제 방식 추가가 용이함
class CryptoPayment implements PaymentMethod {
    public void processPayment() { ... }
}

 

적용 방법 : 

• 추상화와 다형성을 활용
• 인터페이스 기반 설계로 기능 확장이 필요할 때 구현체만 추가

스프링 적용 사례 :

• DI를 통해 새로운 구현체를 주입하고, 클라이언트 코드는 수정하지 않음

3. 리스코프 치환 원칙 (Liskov Substitution Principle, LSP)

하위 클래스는 상위 클래스의 규약을 지켜야 한다는 원칙으로, 상위 타입의 객체를 하위 타입의 객체로 치환해도 프로그램의 정확성이 보장되어야 함을 의미한다.

// LSP를 위반하는 예시
class Bird {
    void fly() { ... }
}

class Penguin extends Bird {
    void fly() {
        throw new UnsupportedOperationException(); // 펭귄은 날 수 없음!
    }
}

// LSP를 준수하는 예시
interface FlyingBird {
    void fly();
}

interface WalkingBird {
    void walk();
}

class Sparrow implements FlyingBird {
    public void fly() { ... }
}

class Penguin implements WalkingBird {
    public void walk() { ... }
}

 

적용 이유 : 상속 관계에서의 일관성 유지

적용 방법 :

• 잘못된 상속 구조를 인터페이스로 재설계
• 비슷한 기능을 공유하는 객체는 상속보다 컴포지션을 고려

4. 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다.

// ISP를 위반하는 예시
interface Worker {
    void work();
    void eat();
    void sleep();
}

// ISP를 준수하는 예시
interface Workable {
    void work();
}

interface Eatable {
    void eat();
}

interface Sleepable {
    void sleep();
}

class Human implements Workable, Eatable, Sleepable {
    public void work() { ... }
    public void eat() { ... }
    public void sleep() { ... }
}

class Robot implements Workable {
    public void work() { ... }
}



적용 방법 :

• 작은 단위의 인터페이스로 분리
• 클라이언트가 필요한 기능만 제공

적용 예시 :

• 스프링 빈 등록 시 특정 인터페이스를 구현한 구현체만 사용 가능

5. 의존관계 역전 원칙 (Dependency Inversion Principle, DIP)

"상위 모듈은 하위 모듈의 구현에 의존해서는 안 되며, 둘 다 추상화에 의존해야 하고,

추상화가 세부 사항에 의존하는 것이 아닌 세부사항이 추상화에 의존해야 한다"

즉, 상위와 하위 객체 모두가 동일한 추상화에 의존해야 한다.

// DIP를 위반하는 예시
class OrderService {
    private MySQLOrderRepository repository = new MySQLOrderRepository();
}

// DIP를 준수하는 예시
interface OrderRepository {
    void save(Order order);
}

class OrderService {
    private final OrderRepository repository;

    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }
}

 

적용 이유 :

• 모듈 간 결합도를 낮추고 유연성을 높임
• 상위 모듈 로직 변경 없이 하위 수준의 구현 변경 가능

적용 예시 :

• DI 컨테이너로 의존성을 주입
• 설정 파일, 애너테이션을 통해 유연한 구조 제공

SOLID 원칙의 실제 적용

SOLID 원칙들은 개별적으로도 중요하지만, 서로 긴밀하게 연관되어 있다. 원칙들을 적절히 적용하면 다음과 같은 이점을 얻을 수 있다.

• 코드의 유지보수성 향상
• 확장성 있는 설계 가능
• 재사용 가능한 컴포넌트 생성
• 테스트가 용이한 코드 작성

하지만, 이러한 원칙들을 과도하게 적용하면 오히려 코드가 복잡해질 수 있으므로, 상황에 맞게 적절히 적용하는 것이 중요하다.

특히, 초기 단계에서는 단순한 설계로 시작하고, 필요에 따라 점진적으로 원칙들을 적용하는 것이 좋다.

따라서, 이러한 원칙들은 단순히 규칙으로 외우기보다는, 왜 필요한지, 어떤 상황에서 적용해야 하는지를 이해하는 것이 중요하다. 

스프링 프레임워크와 객체 지향 설계의 만남

스프링이 해결하고자 했던 문제

객체 지향 프로그래밍의 핵심 원칙인 OCP(개방-폐쇄 원칙)와 DIP(의존관계 역전 원칙)를 실제 코드에 적용하는 것은 생각보다 많은 작업을 필요로 한다. 이러한 문제를 해결하기 위해 스프링 프레임워크가 탄생했다.

스프링이 없을 때의 문제점

// 인터페이스와 구현체
interface PaymentService {
    void processPayment();
}

class KakaoPayService implements PaymentService {
    public void processPayment() {
        System.out.println("카카오페이 결제 처리");
    }
}

class NaverPayService implements PaymentService {
    public void processPayment() {
        System.out.println("네이버페이 결제 처리");
    }
}

// 클라이언트 코드
class OrderService {
    private PaymentService paymentService = new KakaoPayService();  // DIP 위반!

    public void order() {
        paymentService.processPayment();
    }
}

 

위 코드의 문제점

• 다른 결제 서비스로 변경하려면 OrderService 코드를 수정해야 함 (OCP 위반)
• OrderService가 구체적인 결제 서비스인 KakaoPayService를 직접 생성(상위 모듈이 하위 모듈에 의존)하고 있음 (DIP 위반)

스프링의 해결책: DI(Dependency Injection)

// 스프링 방식으로 변경
@Service
class OrderService {
    private final PaymentService paymentService;

    @Autowired
    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    public void order() {
        paymentService.processPayment();
    }
}

@Service
class KakaoPayService implements PaymentService {
    public void processPayment() {
        System.out.println("카카오페이 결제 처리");
    }
}

 

OrderService는 생성자 주입을 통해 PaymentService의 추상화에 의존하므로, 새로운 결제 수단을 추가할 때 기존 코드를 수정하지 않고도 확장이 가능하다. (OCP 준수)

OrderService가 PaymentService라는 추상화에 의존하고 있으며, 구현체는 외부에서 주입된다. (DIP 준수)

 

장점

• DI 컨테이너가 객체의 생성과 의존관계 주입을 담당
• 설정 변경만으로 구현체를 변경할 수 있음 (모킹(mocking)이나 다른 구현체로의 교체가 용이)
• 클라이언트 코드의 변경 없이 기능 확장 가능

역할과 구현의 분리

스프링은 객체 지향의 핵심 원칙인 "역할과 구현의 분리"를 매우 잘 지원한다.

// 역할(인터페이스)
public interface MemberRepository {
    void save(Member member);
    Member findById(Long id);
}

// 구현
@Repository
public class JpaMemberRepository implements MemberRepository {
    @Override
    public void save(Member member) {
        // JPA를 사용한 구현
    }

    @Override
    public Member findById(Long id) {
        // JPA를 사용한 구현
    }
}

@Repository
public class MongoMemberRepository implements MemberRepository {
    // MongoDB를 사용한 구현
}

 

역할과 구현을 분리한 설계의 장점

• 데이터베이스를 변경하더라도 클라이언트 코드는 변경할 필요가 없음
• 테스트가 용이함 (Mock 객체 사용 가능)
• 기능 확장이 쉬움

 

결론

스프링 프레임워크는 객체 지향의 핵심 원칙들을 실천할 수 있도록 도와주는 도구이다. DI 컨테이너를 통해 유연성과 확장성을 제공해주어, 개발자는 비즈니스 로직에 더 집중할 수 있게 된다.

 

 

 

참고 자료 :

스프링 기본 강의 (김영한 강사)

https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)

SOLID (객체 지향 설계) - 위키백과, 우리 모두의 백과사전