소프트웨어 개발에서 코드 유지 관리, 확장 및 유연성은 프로젝트의 장기적인 성공에 중요합니다. SOLID 원칙은 개발자가 더 쉽게 이해하고, 수정하고, 확장할 수 있는 코드를 만들 수 있도록 안내하기 위해 만들어졌습니다. 이 글에서는 5가지 SOLID 원칙 각각과 이를 Java의 실제 예제와 함께 사용하는 방법에 대해 설명합니다.

1. 단일 책임 원칙

단일 책임 원칙(SRP)은 클래스가 변경해야 하는 이유가 하나만 있어야 함, 즉 시스템 내에서 단일 책임을 가져야 함을 설정합니다.

// Antes de aplicar o SRP
class ProductService {
    public void saveProduct(Product product) {
        // Lógica para salvar o produto no banco de dados
    }

    public void sendEmail(Product product) {
        // Lógica para enviar um email sobre o produto
    }
}

// Após aplicar o SRP
class ProductService {
    public void saveProduct(Product product) {
        // Lógica para salvar o produto no banco de dados
    }
}

class EmailService {
    public void sendEmail(Product product) {
        // Lógica para enviar um email sobre o produto
    }
}

이 예에서는 데이터베이스에 제품을 저장하는 책임과 제품에 대한 이메일을 보내는 책임을 분리합니다. 이메일 전송 시 변경 사항이 더 이상 제품 저장 논리에 영향을 미치지 않으므로 향후 변경이 용이해집니다.

2. 개방/폐쇄 원칙

OCP(개방/폐쇄 원칙)는 소프트웨어 엔터티(클래스, 모듈, 기능 등)가 확장을 위해 개방되어야 하고 수정을 위해 폐쇄되어야 한다고 제안합니다. 이는 추상화와 상속을 통해 달성됩니다.

// Exemplo inicial violando o OCP
class AreaCalculator {
    public double calculateArea(Rectangle[] rectangles) {
        double area = 0;
        for (Rectangle rectangle : rectangles) {
            area  = rectangle.width * rectangle.height;
        }
        return area;
    }
}

// Exemplo após aplicar o OCP
interface Forma {
    double calculateArea();
}
class Rectangle implements Forma {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }
    @Override
    public double calculateArea() {
        return width * height;
    }
}

class AreaCalculator {
    public double calculateArea(Forma [] formas) {
        double area = 0;
        for (Forma formas: formas) {
            area  = forma.calculateArea();
        }
        return area;
    }
}

이 두 번째 예에서 처음에는 AreaCalculator 클래스가 Rectangle 클래스에 직접적으로 종속되었습니다. 즉, 원이나 삼각형과 같은 다른 유형의 도형을 추가하려면 AreaCalculator 클래스를 수정해야 하므로 OCP를 위반해야 합니다. Shape 인터페이스의 생성으로 AreaCalculator 클래스는 기존 코드를 수정하지 않고도 새로운 기하학적 모양을 받을 수 있습니다.

3. 리스코프 대체 원칙

리스코프 대체 원칙(LSP)은 슈퍼클래스의 객체가 시스템 무결성에 영향을 주지 않고 서브클래스의 객체로 대체 가능해야 한다고 명시합니다. 즉, 하위 클래스의 동작은 슈퍼클래스의 동작과 일치해야 합니다.

// Classe base
class Bird {
    public void fly() {
        // Método padrão que imprime "Flying"
        System.out.println("Flying");
    }
}

// Classe derivada que viola o LSP
class Duck extends Bird {
    @Override
    public void fly() {
        // Sobrescrita que imprime "Ducks cannot fly"
        System.out.println("Ducks cannot fly");
    }
}

문제: Duck 클래스는 fly() 메서드를 재정의하여 "Ducks can fly"를 인쇄하므로 모든 새가 나는("Flying") Bird 기본 클래스에 정의된 기본 동작을 변경합니다. 이는 Bird 객체나 그 하위 클래스가 날 것으로 예상하는 코드가 날지 않는 Duck과 함께 올바르게 작동하지 않기 때문에 LSP를 위반합니다.

// Classe derivada que respeita o LSP
interface Bird {
    void fly();
}
class Eagle implements Bird {
    @Override
    public void fly() {
        System.out.println("Flying like an Eagle");
    }
}
class Duck implements Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Ducks cannot fly");
    }
}

이 접근 방식을 사용하면 Bird 인터페이스에서 설정한 기대를 깨지 않고 Bird가 예상되는 곳에서 Eagle과 Duck을 상호 교환할 수 있습니다. Duck이 던진 예외는 코드에서 예상치 못한 문제를 일으킬 수 있는 방식으로 슈퍼클래스의 동작을 수정하지 않고 오리가 날지 않는다는 것을 명시적으로 전달합니다.

4. 인터페이스 분리 원칙

ISP(인터페이스 분리 원칙)는 클래스의 인터페이스가 이를 사용하는 클라이언트에 따라 달라야 함을 제안합니다. 이렇게 하면 클라이언트가 사용하지 않는 메서드 구현이 필요한 "두꺼운" 인터페이스를 피할 수 있습니다.

// Exemplo antes de aplicar o ISP
interface Worker {
    void work();
    void eat();
    void sleep();
}

class Programmer implements Worker {
    @Override
    public void work() {
        // Lógica específica para programar
    }
    @Override
    public void eat() {
        // Lógica para comer
    }
    @Override
    public void sleep() {
        // Lógica para dormir
    }
}

// Exemplo após aplicar o ISP
interface Worker {
    void work();
}
interface Eater {
    void eat();
}
interface Sleeper {
    void sleep();
}
class Programmer implements Worker, Eater, Sleeper {
    @Override
    public void work() {
        // Lógica específica para programar
    }
    @Override
    public void eat() {
        // Lógica para comer
    }
    @Override
    public void sleep() {
        // Lógica para dormir
    }
}

예제에서는 Worker 인터페이스를 더 작은 인터페이스(Work, Eat, Sleep)로 분할하여 이를 구현하는 클래스에 필요한 메서드만 있는지 확인합니다. 이렇게 하면 클래스가 관련되지 않은 메서드를 구현하지 않아도 되므로 코드 명확성과 응집력이 향상됩니다.

5. 의존성 역전 원리

DIP(종속성 역전 원칙)는 상위 수준 모듈(예: 주요 비즈니스 규칙을 구현하는 비즈니스 또는 애플리케이션 클래스)이 하위 수준 모듈(외부 데이터에 대한 액세스와 같은 인프라 클래스 및 높은 수준의 작업을 지원하는 서비스). 둘 다 추상화에 의존해야 합니다.

// Exemplo antes de aplicar o DIP
class BackendDeveloper {
    public void writeJava() {
        // Lógica para escrever em Java
    }
}
class Project {
    private BackendDeveloper developer;

    public Project() {
        this.developer = new BackendDeveloper();
    }
    public void implement() {
        developer.writeJava();
    }
}

// Exemplo após aplicar o DIP
interface Developer {
    void develop();
}
class BackendDeveloper implements Developer {
    @Override
    public void develop() {
        // Lógica para escrever em Java
    }
}
class Project {
    private Developer developer;

    public Project(Developer developer) {
        this.developer = developer;
    }
    public void implement() {
        developer.develop();
    }
}

이제 프로젝트 클래스는 구체적인 구현(BackendDeveloper) 대신 추상화(개발자)에 의존합니다. 이를 통해 다양한 유형의 개발자(예: FrontendDeveloper, MobileDeveloper)를 코드를 수정하지 않고도 프로젝트 클래스에 쉽게 삽입할 수 있습니다.

결론

SOLID 원칙을 채택하면 코드 품질이 향상될 뿐만 아니라 기술 능력이 강화되고 작업 효율성이 높아지며 소프트웨어 개발자로서의 경력 경로가 향상됩니다.