[SOLID] 간단한 소스코드 예제 (객체 지향 설계 5가지 원칙)

예전에 올린 글이 있습니다. 거기에는 설명을 풀어서 했다면, 이번글은 소스코드를 보여주려고 작성했습니다.

(예전 글 : https://shoney.tistory.com/entry/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-%EC%96%B8%EC%96%B4-SOLID)

SOLID

객체 지향 설계와 SOLID 원칙

객체 지향 설계(Object-Oriented Design)란, 객체(Object)를 중심으로 구성하는 소프트웨어 설계 방법을 뜻합니다. 객체는 데이터와 그 데이터를 처리하는 메소드로 이루어져 있으며, 이러한 객체들이 상호작용함으로써 소프트웨어를 구성합니다.

객체 지향 설계를 하는 과정에서 SOLID 원칙을 적용할 수 있습니다. SOLID 원칙은 객체 지향 설계의 다섯가지 원칙으로, 각각의 알파벳을 따서 SOLID 라고 부릅니다.

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

한 클래스는 하나의 책임만 가져야 합니다. 하나의 클래스가 여러 책임을 가지게 되면, 클래스를 수정할 때 다른 책임에 영향을 끼치게 되고, 코드의 유지보수가 어려워집니다.

// SRP (Single Responsibility Principle)
class Car {
    public void start() {
        // ...
    }

    public void stop() {
        // ...
    }
}

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

확장에는 열려있고, 수정에는 닫혀 있어야 합니다. 새로운 요구사항이 생겨도 기존의 코드는 수정하지 않고, 새로운 코드를 추가하여 변경되는 부분을 대응해야 합니다.

// OCP (Open-Closed Principle)
interface Shape {
    double getArea();
}

class Rectangle implements Shape {
    private double width;
    private double height;

    public double getArea() {
        return width * height;
    }
}

class Circle implements Shape {
    private double radius;

    public double getArea() {
        return Math.PI * radius * radius;
    }
}

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

자식 클래스는 부모 클래스에서 가능한 행위를 수행할 수 있어야 합니다. 즉, 상속 관계에서는 자식 클래스가 부모 클래스의 기능을 확장할 수 있어야 합니다.

// LSP (Liskov Substitution Principle)
interface Bird {
    void fly();
}

class Duck implements Bird {
    public void fly() {
        // ...
    }
}

class Ostrich implements Bird {
    public void fly() {
        throw new UnsupportedOperationException();
    }
}

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

클라이언트는 자신이 사용하지 않는 메소드에 의존하도록 강요되어서는 안 됩니다. 인터페이스를 작은 단위로 분리하면, 클라이언트가 자신이 사용하는 메소드만 호출할 수 있습니다.

// ISP (Interface Segregation Principle)
interface Car {
    void drive();
}

interface Airplane {
    void fly();
}

class FlyingCar implements Car, Airplane {
    public void drive() {
        // ...
    }

    public void fly() {
        // ...
    }
}

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

추상화에 의존해야지, 구체화에 의존하면 안 됩니다. 즉, 구체적인 클래스보다는 추상 클래스나 인터페이스에 의존해야 합니다.

// DIP (Dependency Inversion Principle)
interface Database {
    void save(String data);
}

class MySQL implements Database {
    public void save(String data) {
        // ...
    }
}

class User {
    private Database database;

    public User(Database database) {
        this.database = database;
    }

    public void saveData(String data) {
        database.save(data);
    }
}

SOLID 원칙을 적용하면, 유연하고 확장성이 좋은 소프트웨어를 만들 수 있습니다.