[JAVA] 스프링과 객체지향

🟢 객체 지향 프로그래밍이란 ?

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체" 들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메세지를 주고받고, 데이터를 처리할 수 있다. (협력)

객체지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어의 개발에 많이 사용된다.

프로그램을 설계할 때, 자바 언어의 다형성을 활용하여 역할과 구현을 명확히 분리해야 한다.

 

역할 = 인터페이스
구현 = 인터페이스를 구현한 클래스, 구현 객체

 

객체 설계시 역할(인터페이스)를 먼저 부여하고, 그 역할을 수행하는 구현 객체를 만든다.

 

다형성의 본질이란

인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다. 다형성의 본질을 이해하려면 협력이라는 객체사이의 관계에서 시작해야 한다. 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

즉, 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.

 

스프링과 객체지향

다형성이 제일 중요하고, 스프링은 이 다형성을 극대화해서 이용할 수 있게 도와준다. 스프링에서 이야기하는 제어의 역전 (IoC), 의존관계 주입(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.

 

💡 객체지향의 5원칙, SOLID

1. 단일 책임 원칙 (Single Responsibility principle)
2. 개방 폐쇄 원칙 (Open Closed Principle)
3. 리스코프 치환 원칙 (Liscov Substitution Principle)
4. 인터페이스 분리 원칙 (Interface Sergregation Principle)
5. 의존성 역전 원칙 (Dependency Inversion Principle)

1. SRP, 단일 책임 원칙

한 클래스는 하나의 책임만 가져야 한다. 하나의 책임이라는 것은 클 수도 작을 수도 있고, 문맥과 상황에 따라 다르기 때문에 모호하다.

중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이라는 말이다. (UI 변경, 객체의 생성과 사용을 분리)

 

// 사용자의 정보를 취급하는 클래스
class User {
    private String name;
    private String email;

    public User(String name, String email) {
        this.name = name;
        this.email = email;
    }

    // Getters and Setters
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }
}

// 데이터베이스 관련 로직을 처리하는 클래스
class UserRepository {
    public void saveUser(User user) {
        // 여기에 데이터베이스 저장 로직 구현
    }
}

 

위의 코드를 예시로, 사용자 정보를 관리하는 클래스와 사용자의 데이터를 데이터베이스에 저장하는 로직을 분리할 수 있다.

 

2. OCP, 개방 폐쇄 원칙

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현, 다형성의 활용이 가능하다. 기존의 코드를 변경하지 않고도, 클래스의 기능을 확장할 수 있어야 한다.

즉, 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현할 수 있어야 한다. 하지만 이러한 경우에 클라이언트, 즉 코드를 수정해야 하는 문제점이 있지만 깊은 내용이기에 뒤에서 추가로 설명하기로 한다!

 

abstract class Shape {
    abstract double calculateArea();
}

class Rectangle extends Shape {
    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 Circle extends Shape {
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}

 

여기서 'Discount' 클래스는 추상 클래스로, 다양한 할인율을 적용할 수 있도록 확장이 가능하나 기존 할인 계산 로직을 변경할 필요가 없다. 새로운 할인율을 추가하고 싶을 때는 'Discount' 를 상속받는 새로운 클래스를 만들기만 하면 된다.

 

3. LSP, 리스코프 치환 원칙

프로그램 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 즉, 부모 클래스의 인스턴스 대신 자식 클래스의 인스턴스를 사용할 수 있어야 한다는 의미이다. 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.

ex) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP 위반, 느리더라도 앞으로 가야 한다.

class Bird {
    public void fly() {
        System.out.println("This bird can fly.");
    }
}

class Duck extends Bird {
    @Override
    public void fly() {
        System.out.println("Duck flies lower.");
    }
}

class Ostrich extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Ostrich cannot fly.");
    }
}

 

위의 예시에서 Bird 클래스는 fly() 메서드를 가지고 있고, Duck은 이 메서드를 오버라이드하여 다르게 구현한다. 하지만, Ostrich 클래스는 fly() 메서드를 지원하지 않는다. 이 경우 리스코프 치환 원칙에 위배된다. 왜냐하면 Bird 타입의 객체를 Ostrich 객체로 대체했을 때, 프로그램이 실패하게 되기 때문이다.

 

원칙에 맞게 수정된 코드

class Bird {
}

class FlyingBird extends Bird {
    public void fly() {
        System.out.println("This bird can fly.");
    }
}

class Duck extends FlyingBird {
    @Override
    public void fly() {
        System.out.println("Duck flies lower.");
    }
}

class Ostrich extends Bird {
    // Ostrich 클래스는 FlyingBird를 상속받지 않음
}

 

 

위 수정된 예시에서, 비행 가능한 새들을 위한 별도의 클래스 FlyingBird가 도입되었다. 이로써, Ostrich는 비행을 구현하는 클래스를 상속받지 않으므로, Bird 타입의 객체를 Ostrich 객체로 대체하는 상황에서 비행 기능을 호출할 일이 없어지며 리스코프 치환 원칙을 준수하게 된다.

 

4. ISP, 인터페이스 분리 원칙

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 예를 들어 자동차 인터페이스를 운전 & 정비 인터페이스로 분리하고 사용자 클라이언트를 운전자 & 정비사 클라이언트로 분리한다. 분리하면 정비 인터페이스 자체가 변경되도 운전자 클라이언트에 영향을 주지 않는다. 인터페이스가 명확해지고, 대체 가능성이 높아진다.

 

interface Printer {
    void printDocument(String document);
}

interface Scanner {
    void scanDocument(String document);
}

class SimplePrinter implements Printer {
    public void printDocument(String document) {
        // Printing logic
    }
}

class MultiFunctionMachine implements Printer, Scanner {
    public void printDocument(String document) {
        // Printing logic
    }

    public void scanDocument(String document) {
        // Scanning logic
    }
}

 

이 예시에서 `SimplePrinter` 는 인쇄 기능만 필요로 하고,  `MultiFunctionMachine`은 인쇄와 스캔 기능 모두를 필요로 한다. 각각의 클래스는 자신이 필요로 하는 인터페이스만 구현하면 된다.

 

5. DIP, 의존관계 역전 원칙

"추상화에 의존해야지, 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나다. 즉, 클라이언트 코드가 구현 클래스에 바라보지 말고(의존하지 말고), 인터페이스에 의존하라는 의미이다. 역할에 의존하게 해야 한다는 것과 같다. 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다. 구현체에 의존하게 되면 변경이 어려워진다.

추가로 하나의 예시를 들자면 Member Service 가 MemberRepository Interface 만 바라봐야 하며, 그 구현체에 대해서는 몰라야 한다는 의미이다.

interface Storage {
    void saveData(String data);
}

class DiskStorage implements Storage {
    public void saveData(String data) {
        // Save data to disk
    }
}

class CloudStorage implements Storage {
    public void saveData(String data) {
        // Save data to cloud
    }
}

class DataManager {
    private Storage storage;

    public DataManager(Storage storage) {
        this.storage = storage;
    }

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

 

`DataManager` 클래스는 구체적인 `Storage` 구현체에 의존하지 않고 `Storage` 인터페이스에 의존한다. 이를 통해 `DataManager`의 저장 메커니즘을 변경할 때 `DataManager` 코드를 변경할 필요 없이,  다른 `Storage` 구현체를 주입하기만 하면 된다.

*️⃣ 정리

스프링은 다음 기술로 다형성 + OCP & DIP 를 가능하게 지원한다.

 

DI (Dependency Injection) = 의존관계, 의존성 주입
DI 컨테이너 제공

 

클라이언트 코드의 변경 없이 기능 확장