[멋쟁이사자처럼 부트캠프 TIL 회고] 백엔드 부트캠프 13기: Java 19일차 OOP, SOLID 원칙

UML

의도는 “메시징”이다. 훌륭하고 성장 가능한 시스템을 만들기 위한 핵심은 모듈 내부의 속성과 행동이 어떤가보다 모듈이 어떻게 커뮤니케이션하는가에 달려있다. - Alan Curtis Kay

 

1. 객체지향 프로그래밍 설계 원칙 개요

1.1 객체지향 프로그래밍(OOP) 핵심 개념

(1) 추상화
(2) 캡슐화
(3) 상속
(4) 다형성

 

https://mmatrix.tistory.com/33

[멋쟁이사자처럼 부트캠프 TIL 회고] 백엔드 부트캠프 13기: Java 5일차 메서드의 선언, 캡상추다,

따로 정리를 했었다. 자세한 내용은 윗글을 참조.

---

1.2 설계 원칙이 중요한 이유

• 코드 유지보수성을 높이기 위함
  • 각 객체가 가진 책임이 분명해지고, 수정 범위가 최소화됨
  • 어느 부분을 고치면 되는지 명확
• 확장성과 유연성 확보
  • 변화 가능 지점을 미리 추상화해, 새로운 기능 추가 시 기존 코드를 크게 수정하지 않아도 됨
• 팀 협업과 커뮤니케이션 원활
  • 클래스/메서드 역할이 명확해 다른 팀원이 코드를 빠르게 파악
  • 코드 리뷰나 리팩토링 효율 증대
• 의존성과 결합도를 줄여 재사용성 향상
  • 모듈 간 결합도는 낮추고 응집도는 높여, 다른 프로젝트에서도 쉽게 재사용 가능

 

1.3 SOLID 원칙

객체지향 프로그래밍에서 코드의 유지보수성과 확장성을 높이기 위해 제안된 다섯 가지 설계 원칙의 약어

 

(1) SRP (Single Responsibility Principle)

 

• 단일 책임 원칙: 클래스는 하나의 책임만 가져야 하며, 단일한 목적을 가져야 합니다.
• 이유: 책임이 많아질수록 변경에 취약해지고, 재사용성이 떨어집니다.

class ReportGenerator {
    public void generateReport() {
        // 보고서 생성 로직
    }
}

class ReportPrinter {
    public void printReport() {
        // 보고서 출력 로직
    }
}

 

- 좋은 예: 보고서 생성과 출력은 서로 다른 책임이므로 두 클래스로 분리.

 

(2) OCP (Open/Closed Principle)

 

• 개방-폐쇄 원칙: 기존 코드는 수정하지 않으면서 확장이 가능해야 한다.
• 이유: 기존 코드를 변경하면 의도치 않은 버그가 발생할 가능성이 높아짐.

 

interface Shape {
    double calculateArea();
}

class Circle implements Shape {
    private double radius;
    public Circle(double radius) {
        this.radius = radius;
    }
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}

class Rectangle implements Shape {
    private double width, height;
    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }
    public double calculateArea() {
        return width * height;
    }
}

- 좋은 예: 새로운 도형이 추가되어도 Shape 인터페이스를 구현하기만 하면 기존 코드를 수정할 필요가 없음.

 

(3) LSP (Liskov Substitution Principle)

 

• 리스코프 치환 원칙: 서브타입은 언제나 기반 타입으로 대체할 수 있어야 한다.
• 이유: 부모 클래스를 사용하는 코드가 자식 클래스로도 정상 동작해야 함.

 

class Bird {
    public void fly() {
        System.out.println("Bird is flying");
    }
}

class Penguin extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Penguins can't fly");
    }
}

- 나쁜 예: Penguin은 Bird를 상속받았지만 fly()를 사용할 수 없음.

interface Flyable {
    void fly();
}

class Sparrow implements Flyable {
    public void fly() {
        System.out.println("Sparrow is flying");
    }
}

class Penguin {
    // Penguins don't implement Flyable
}

- 개선

 

(4) ISP (Interface Segregation Principle)

 

• 인터페이스 분리 원칙: 클라이언트는 자신이 사용하지 않는 메소드에 의존하지 않아야 한다.
• 이유: 불필요한 의존성으로 인해 코드가 복잡해질 수 있음.

interface Animal {
    void eat();
    void fly();
    void swim();
}

class Dog implements Animal {
    public void eat() { /* 구현 */ }
    public void fly() { /* 불필요 */ }
    public void swim() { /* 구현 */ }
}

 

- 나쁜 예: Dog는 날 수 없지만 fly()를 구현해야 함.

interface Eatable {
    void eat();
}

interface Flyable {
    void fly();
}

interface Swimmable {
    void swim();
}

class Dog implements Eatable, Swimmable {
    public void eat() { /* 구현 */ }
    public void swim() { /* 구현 */ }
}

- 개선

(5) DIP (Dependency Inversion Principle)

 

• 의존성 역전 원칙: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다.
• 이유: 구현 세부 사항에 의존하면 변경에 취약해짐.

 

class Light {
    public void turnOn() {
        System.out.println("Light is on");
    }
}

class Switch {
    private Light light;

    public Switch(Light light) {
        this.light = light;
    }

    public void press() {
        light.turnOn();
    }
}

- 나쁜 예: Switch가 Light에 직접 의존.

interface Switchable {
    void turnOn();
}

class Light implements Switchable {
    public void turnOn() {
        System.out.println("Light is on");
    }
}

class Fan implements Switchable {
    public void turnOn() {
        System.out.println("Fan is on");
    }
}

class Switch {
    private Switchable device;

    public Switch(Switchable device) {
        this.device = device;
    }

    public void press() {
        device.turnOn();
    }
}

- 좋은 예: Switch는 추상화된 Switchable에 의존하므로, Light나 Fan을 쉽게 교체 가능.

 

* SOLID 원칙은 코드의 유지보수성, 재사용성, 확장성을 높이는 데 중요한 가이드라인.

  이를 준수하면 변화에 유연한 시스템을 설계할 수 있습니다.