🔎 Overview

  스프링의 원리를 공부하던 도중, 익숙한 단어가 나왔다. SOLID , 좋은 객체 지향 설계의 5가지 원칙이다.
기존에도 당연히 알고 있던 개념이지만 사실상 원리를 이해하기 보다는 단순히 외우고만 있었던 개념이었으므로, 확실하게 알고 있다고는 단정할 수 없었다.
SOLID 는 개발자라면 반드시 알고 실무에서 제대로 사용할 수 있어야 하는 개념이다. 이번 기회에, 보다 좋은 개발자가 될 수 있도록 SOLID 에 대한 확실한 이해를 목표로 학습 및 정리해보았다.

---

📕 SOLID

• 객체 지향 프로그래밍 및 설계에서 사용되는 5가지 기본 원칙
• 소프트웨어의 유지보수성, 가독성, 확장성을 향상시키는 것이 목표
  
  
  

📌 5가지 원칙

1️⃣ SRP (Single Responsibility Principle)

• 단일 책임 원칙
• 하나의 클래스는 반드시 하나의 책임만 가져야 함
  • 책임은 하나의 기능이라기보다는, 해당 클래스가 변경되어야 할 단 하나의 이유
  • 여러 이유로 변경될 수 있다면 SRP 위반
  • 한 가지 책임에 집중할 수 있도록, 클래스를 적절히 분리해서 설계해야 한다는 원칙
• 책임의 기준 및 범위는 개발자마다 다를 수 있음
  • MemberService 에 회원 도메인에 대한 로직을 모아두어도 (하나의 클래스에 하나의 기능만 존재하지 않더라도), 회원이라는 일관된 책임 내에서 동작하므로 SRP 위반이 아님

// SRP 위반
public class memberService {
	public void join(Member member) {
    	// 회원 저장
    }
    
    public void sendMail(Member member) {
    	// 이메일 발송
    }
}

• 회원 저장과 이메일 발송이라는 서로 다른 두 가지 책임을 가지고 있으므로, SRP 위반

// SRP 준수
public class MemberService {
	public void join(Member member) {
    	// 회원 저장
    }
}

public class EmailService {
	public void sendMail(Member member) {
    	// 이메일 발송
    }
}

• MemberService 는 회원 도메인에만, EmailService 는 이메일 도메인에만 집중하므로, SRP 준수
  
  

2️⃣ OCP (Open Closed Principle)

• 개방-폐쇄 원칙
• 소프트웨어는 확장에는 열려있고 변경에는 닫혀있어야 함
  • 기능 추가 및 변경 시 클래스 확장을 통해 쉽게 구현할 수 있도록 하되, 기존 클래스의 수정은 최소화할 수 있도록 설계
  • 역할과 구현의 분리
• 다형성을 활용
  • 인터페이스를 활용하고, 정책에 따라 다양한 구현체를 제공
  • 객체지향의 장점을 극대화할 수 있음
• 스프링은 IOC 및 DI 를 통해 해당 원칙을 준수할 수 있도록 설계되어있음

// OCP 위반
public class DiscountService {
	public int getNormalDiscountRate() {
    	// 할인율 로직
    }
}

• VIP , GOLD 등 새로운 정책 추가 시 클래스 수정 필요

// OCP 준수
public interface DiscountPolicy{
	int getDiscountRate();
}

public class VipDiscountPolicy implements DiscountPolicy {
	public int getDiscountRate() {
    	// VIP 할인율 로직
    }
}

public class NormalDiscountPolicy implements DiscountPolicy {
	public int getDiscountRate() {
    	// 일반 할인율 로직
    }
}

public class DiscountService {
	private final DiscountPolicy discountPolicy;
    
    public DiscountService(DiscountPolicy discountPolicy) {
    	this.discountPolicy = discountPolicy;
    }
    
    public int discount() {
    	return discountPolicy.getDiscountRate();
    }
}

• 새 정책 추가 시, DiscountPolicy 구현체만 추가하여 주입하면 됨
  
  

3️⃣ LSP (Liskov Substitution Principle)

• 리스코프 치환 원칙
• 하위 타입은 언제나 상위 타입으로 교체할 수 있어야 함
  • 다형성을 제대로 활용하기 위한 원칙
  • 상위 클래스 타입으로 하위 클래스 객체를 받더라도 (업캐스팅), 기능이 원하는대로 동작해야 한다는 의미
  • 기능적 의미를 해치는, 부적절한 오버라이딩을 하지 않도록 설계
  • 부모의 sleep() 이라는 잠자는 의미의 메서드를, 자식이 달리기라는 의미로 오버라이딩하면 LSP 원칙을 위반

// LSP 위반
class Parent {
	int[] location = {0, 0};
    
	void sleep() {
    	try {
    		Thread.sleep(1000);
        } catch (InterruptedException e) {}
    }
}

class Child extends Parent {
	@Override
    void sleep() {
    	location[0]++;
    }
}

• 부모는 쓰레드 대기의 의미로 sleep() 메서드를 구현했지만, 자식은 움직이기의 의미로 sleep() 메서드를 오버라이딩
  • 메서드의 의도와 의미가 전혀 달라지므로 LSP 위반

// LSP 준수
class Parent {
	int[] location = {0, 0};
    
	void sleep() {
    	try {
    		Thread.sleep(1000);
        } catch (InterruptedException e) {}
    }
}

class Child extends Parent {
	@Override
	void sleep() {
    	try {
    		Thread.sleep(2000);
        } catch (InterruptedException e) {}
    }
}

• 부모와 자식 모두 쓰레드 대기의 의미로 sleep() 메서드를 구현
  
  
  

4️⃣ ISP (Interface Segregation Principle)

• 인터페이스 분리 원칙
• 인터페이스 하나에 많은 기능을 담기보다는, 각각의 사용처에 맞게 여러 개로 분리해야 함
  • SRP 는 클래스 분리의 원칙이라면, ISP 는 인터페이스 분리의 원칙
• 특정 클라이언트를 위해 적합한 인터페이스만을 제공하는 것이 목표
• 인터페이스를 한 번 구성해뒀으면 웬만해서는 변경시키면 안됨
• 인터페이스가 보다 명확해지고, 대체 가능성의 증가로 유지보수성 향상

// ISP 위반
interface Machine {
	void print();
    void scan();
    void fax();
}

class PrintMachine implements Machine {
	public void print() {
    	// 프린트
    }
    
    public void scan() {
    	throw new RuntimeException("스캔은 사용할 수 없음");
    }
    
    public void fax() {
    	throw new RuntimeException("팩스는 사용할 수 없음");
    }
}

• PrintMachine 은 프린트 기능만 필요하지만, scan() , fax() 도 반드시 구현해야 하므로 ISP 위반

// ISP 준수
interface Printer {
	void print();
}

interface Scanner {
	void scan();
}

class PrintMachine implements Printer {
	public void print() {
    	// 프린트
    }
}

• PrintMachine 은 프린트에 필요한 Printer 인터페이스만 구현하면 됨
  
  

5️⃣ DIP (Dependency Inversion Principle)

• 의존관계 역전 원칙
• 구체화에 의존해선 안되고, 추상화에 의존해야 함
  • 구현 클래스에 의존하지 말고, 인터페이스에 의존할 것
  • 역할에 의존하도록 설계
  • 변경되기 쉬운 것보다 변경되기 어려운 것에 의존하도록 설계
• 클래스간의 결합도를 낮추는 것이 목표
• 스프링은 IOC 및 DI 를 통해 해당 원칙을 준수할 수 있도록 설계되어있음

// DIP 위반
public class OrderService {
	private final DiscountPolicy discountPolicy = new VipDiscountPolicy();
    
    public int order() {
    	return discountPolicy.getDiscountRate();
    }
}

• VipDiscountPolicy 에 의존하고 있으므로, 다른 정책으로 변경을 원하면 해당 클라이언트 코드의 수정이 필요

// DIP 준수
public class OrderService {
	private final DiscountPolicy discountPolicy;
    
    public OrderService(DiscountPolicy discountPolicy) {
    	this.discountPolicy = discountPolicy;
    }
    
    public int order() {
    	return discountPolicy.getDiscountRate();
    }
}

• 외부에서 DiscountPolicy 구현체를 주입하므로, 정책에 따라 자유롭게 교체할 수 있음
• 스프링에서는 @Component , @Autowired 등의 기능을 통해 이 구조를 쉽게 구현 가능

---

참고) OpenAI. (2024).ChatGPT(4o)[Large language model].https://chatgpt.com/