SOLID 원칙 : 객체 지향 설계 원칙

2025. 3. 4. 10:43Java/객체지향

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

  • 클래스는 단 하나의 책임만 가져야 한다.
  • 하나의 클래스가 변경되어야 하는 이유는 단 하나뿐이어야 한다.
  • 예: 보고서 생성과 저장 두가지 역할을 하는 클래스 -> 보고서 생성, 파일 저장 클래스로 분리

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

  • 소프트웨어 요소(클래스, 모듈, 함수 등)는 확장에 열려 있고, 수정에는 닫혀 있어야 한다. 
  • 새로운 기능이 추가될 때 기존 코드를 수정하지 않고도 확장할 수 있어야 한다.
  • 다형성 (인터페이스와 추상 클래스)를 활용한다.
  • 예: Payment 인터페이스를 사용해서 신용카드, 카카오페이 등의 결제수단 클래스를 구현한다.
    그리고  결제를 진행하는 메서드의 매개변수 타입을 Payment로 선언해 결제수단 추가시에도 메서드를 수정할 필요 없도록 한다. 

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

  • 서브클래스는 언제나 부모 클래스를 대체할 수 있어야 한다.
  • 하위 클래스는 인터페이스 규약을 모두 지켜야하며, 부모 클래스의 기능을 변경하거나 제거해서는 안 된다.
  • 예: Bird 클래스를 상속받은 Penguin 클래스가 부모의 fly() 함수를 제거하고 사용해선 안됨   

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

  • 인터페이스는 특정 클라이언트에 필요한 기능만 포함해야 한다.
  • 하나의 인터페이스가 너무 많은 기능을 제공하면 클라이언트가 불필요한 메서드를 구현해야 한다.
    작은 인터페이스로 나누어 필요한 기능만 사용할 수 있도록 해야 한다.
  • 예: 자동차 인터페이스 -> 운전, 정비 인터페이스로 분리 

5. 의존 역전 원칙 (DIP: Dependency Inversion Principle)

  • 고수준 모듈은 저수준 모듈에 의존하지 말고, 둘 다 추상화에 의존해야 한다.
  • “추상화(인터페이스)에 의존해야지, 구체화(클래스)에 의존하면 안된다”
  • 클래스 간의 결합도를 낮추어 유지보수성, 유연성을 늘려야 한다. 
  • 예시
    • Computer 클래스가 MechanicalKeyboard 라는 클래스를 멤버로 선언하여 의존하면, 나중에 다른 Keyboard를 사용하고 싶은 경우 Computer 클래스를 다 바꾸어야함
    • Keyboard라는 인터페이스를 만들어서  Computer 클래스가 Keyboard 인터페이스를 의존하도록 만듦
    • 의존성 주입: Computer 생성자를 통해 Keyboard 인스턴스를 전달받음