객체 지향 설계와 스프링

🚀 스프링이란?

1. DI container 기술?

스프링 빈을 관리하는 기술

2.스프링 프레임워크?

3.스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계

 

핵심은 좋은 객체 지향 어플리케이션을 개발할 수 있게 도와주는 프레임워크라는 점이다

 

🚀 좋은 객체 지향 프로그래밍이란?

객체 지향의 특성

1. 추상화

2.캡슐화

3.상속

4.다형성

 

대규모 소프트웨어 개발에서 결국 중요한건 다형성

유연하게 변경 가능하기 때문이다

역할과 구현을 구분하여 보자

자동차의 역할을 세개의 자동차에 부여

k3 타다가 아반떼를 타도 운전을 할 수 있다

운전자에게 영향을 주지 않는다

자동차 역할을 k3에서 테슬라로 바꿔도 운전자는 운전을 할 수 있다.

왜? 자동차 인터페이스로 기능의 큰 그림은 짜놨기 때문에

 

클라이언트는 내부 동작을 몰라도 된다

자동차 세상을 무한히 확장 가능하다!

 

 

정리

역할과 구현으로 구분하면 세상이 단순해진다

클라이언트는 내부 구조를 전혀 몰라도 된다

대상 자체를 변경해도 영향을 받지 않는다 왜? 역할은 그대로니깐

다형성

역할 = 인터페이스

구현=구현 객체 클래스

역할과 구현을 명확하게 분리하고

객체 협력이라는 관계부터 생각하자.

 

다형성의 본질

실행 시점에 유연하게 변경할 수 있다

클라이언트를 변경하지 않고 서버의 기능 구현을 유연하게 하는것이 본질이다.

 

🚀좋은 객체 지향 설계의 본질

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

하나의 클래스는 하나의 책임만!!

그러나 이것이 매우 모호함

그래서 중요한 기준은 변경이다.

변경하기 쉽도록 하는 경계까지 단일 책임을 부여

 

2.OCP(Open/Closed Principle) - 개발-폐쇄 법칙

매우 중요!!

 

확장에는 열려 있으나 변경에는 닫혀 있어야 한다

이거를 DI와 IOC로 해줌

코드로 해봐야 알 수 있다

문제가 있다는 것만 인지

 

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

자식 클래스는 부모 클래스에서 기대한 동작을 그대로 구현하거나 그보다 더 나은 동작을 구현해야 한다.

자식 클래스가 부모 클래스에서 정의된 동작을 변경하거나 예기치 않은 동작을 하지 않아야 한다.

 

 

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

기능에 맞게 잘 쪼개는게 중요

즉 하나의 큰 인터페이스보다 여러 개의 작은 인터페이스를 사용하는 것이 좋다는 원칙입니다.

 

 

5.DIP(Dependency Inversion Principle) - 의존 관계 역전 원칙

매우 중요!!

상위 모듈이 하위 모듈에 의존하지 않고, 하위 모듈이 상위 모듈에 의존하지 않도록 해야 한다는 원칙

 

추상화에 의존해야지 구체화에 의존하면 안된다

운전자는 k3에 대해 디테일하게 알 필요가 없다 그냥 역할만 알면된다

즉 역할이 중요하다 인터페이스가 중요하다

역할에 의존해야 된다 구현에 의존하면 안된다.

 

class LightBulb {
    public void turnOn() {
        System.out.println("LightBulb turned on");
    }
    public void turnOff() {
        System.out.println("LightBulb turned off");
    }
}

class Switch {
    private LightBulb bulb;
    
    public Switch(LightBulb bulb) {
        this.bulb = bulb;
    }

    public void operate() {
        System.out.println("Switching...");
        bulb.turnOn();
    }
}

Switch가 LightBulb에 의존한다 -->DIP 위반

 

 

interface Switchable {
    void turnOn();
    void turnOff();
}

class LightBulb implements Switchable {
    @Override
    public void turnOn() {
        System.out.println("LightBulb turned on");
    }

    @Override
    public void turnOff() {
        System.out.println("LightBulb turned off");
    }
}

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

    @Override
    public void turnOff() {
        System.out.println("Fan turned off");
    }
}

class Switch {
    private Switchable device;

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

    public void operate() {
        System.out.println("Switching...");
        device.turnOn();
    }
}

DIP를 잘 지킨 예시

 

🚀Why Spring?

의존성 주입 (DI, Dependency Injection)

 

**DI (Dependency Injection)**는 객체들이 자신이 필요한 의존성을 외부에서 주입받는 방식을 말합니다. 의존성 주입은 객체의 생성과 의존 관계를 외부에서 설정해주는 패턴입니다.

 

즉, 클래스나 객체가 **필요한 의존성(Dependency)**을 직접 생성하지 않고, 외부에서 주입(Injection) 받는 방식입니다. 이 방식은 객체가 자신을 생성하는 책임을 지지 않고, 의존성을 외부에서 주입받기 때문에 결합도를 낮추고, 재사용 가능성을 높이고,

테스트가 용이해집니다.

 

DI의 주요 이점:

• 결합도 감소: 객체가 직접 다른 객체를 생성하거나 의존성을 명시하지 않으므로, 각 객체의 결합도가 낮아집니다. 이는 유지보수와 확장에 유리한 구조를 만듭니다.

• 유연성: 의존성의 교체가 쉬워집니다. 예를 들어, 특정 클래스의 의존성을 교체하고자 할 때, 기존 코드를 변경하지 않고 새로운 구현을 주입만 하면 됩니다.

• 테스트 용이성: DI를 사용하면 Mock 객체나 Stub 객체를 주입하여 유닛 테스트를 쉽게 할 수 있습니다.

 

즉 자동차 부품 교체하듯이  객체 지향 원칙을 잘 지키며 개발할 수 있도록 도와주기 때문에 Spring을 사용하는 것!