1. Spring Framework의 특징과 싱글톤 패턴

Frame + work

프레임의 사전적 의미는 틀, 뼈대

 

개발에서 애플리케이션을 상품이라고 할 때

프레임워크는 상품을 효율적으로 만들기 위해서

틀에 맞춰서 제작하는 것과 비슷하다

---

Spring Framework

---

특징

• POJO

Plain Old Java Object

순수한 자바 객체만을 사용해서 코드를 작성함을 의미한다

 

순수 자바 외에 다른 기술 A를 함께 사용하는 경우

해당 기술이 업데이트 되어 새로운 기능이 추가되었다고 한다면

그 기능을 사용하기 위해서 코드를 뜯어고쳐야한다

 

이 뿐만 아니라 아예 더 상위호환되는 새로운 기술 B가 나왔다고 하면

기존에 사용하던 A를 위한 코드 전부를 수정해야하고

해당 기술에 의존적이었을 수록 수정해야하는 것은 많아진다

 

POJO를 지키면서 개발하는 것은 유연하면서도 단순하게 만드는 것이다.

 

POJO는 아래 세가지를 통해서 완성될 수 있다.

---

• IoC/DI

Inversioin of Control / Dependency Injection

제어의 역전 / 의존관계 주입

 

제어의 역전 : 제어권이 사용자가 아닌 외부에 있는 것

의존관계 주입 : 직접적으로 의존하는 것이 아니라 외부에서 의존관계를 연결해 주는 것

+ 추가예정

---

• AOP

Aspect Oriented Programming

관심 지향 프로그래밍

 

음료수 자판기를 프로그래밍 한다고 할때

돈을 넣고, 넣은 금액을 확인하고, 가격에 맞는 음료를 표시하고,

버튼을 누르면 음료가 나오는 등 직접적으로 자판기의 기능과 관련된 기능을 핵심 기능이라고 하면

 

자판기에 이상이 생겼을때 작동을 중지시킨다거나 오류메세지를 표시하는 등

기계라면 보편적으로 있어야하는 기능을 기술 지원, 공통 기능이라고 할 수 있다

 

이렇게 한 어플리케이션에 있는 다양한 기능을

핵심 기능과 공통 기능으로 나눠서 관리하는 것을 관심 지향 프로그래밍이라고 한다

---

• PSA

Portable Service Abstraction

추상화

 

직역하면 '일관성 있는 서비스 추상화'다

 

https://zazilgure.tistory.com/249

0. SOLID와 Spring

여기에서 예를 들었듯

할인 정책을 변경해야할때 구체적인 코드로 구현하면 변경할때 이전 코드를 모두 갈아엎어야할 수 있다.

하지만 할인 정책을 인터페이스로 추상화해서 각 할인정책이 discount메서드를 구현한 뒤 할인 금액만 반환하도록 해주면

복잡한 코드 수정 없이 기능을 변경할 수 있다.

 

---

싱글톤

이전 글에서 자바만으로 SOLID를 지키기 어려움을 설명하면서 싱글톤에 대해 언급했다

싱글톤이 적용되지 않은 것은 음식점에서 손님이 올때마다 메뉴판을 새로 프린트해서 주는것과 같다

 

메뉴판과 같이 모든 요청에 공통되는 요소는 하나를 공유할 수 있도록 만드는 것이 효율적이다

아래는 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 싱글톤 패턴 이다.

public class SingletonService {
    //1.
    private static final  SingletonService instance = new SingletonService();
    
    //2.
    public  static SingletonService getInstance(){
        return instance;
    }
    
    //3.
    private SingletonService(){
    }
    
    public void logic(){
        System.out.println("싱글톤 객체 로직 호출");
    }
}

1. static 영역에 객체를 단 하나만 생성해둔다
2. public으로 설정해서 객체 인스턴스가 필요하면 이 메서드로만 조회할 수 있도록 한다
3. 생성자를 private로 선언해서 외부에서 객체 생성을 할 수 없게 만든다.

이처럼 싱글톤 패턴으로 만들면 수많은 고객의 요청에도

이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다

 

 

하지만 싱글톤 패턴은 여러 문제점을 가지고 있다

 

1. 코드가 길다. 공유하는 객체가 여러개라면 더 복잡해진다

2. 객체를 사용하기 위해서 구체 클래스에 의존하게 되어 DIP를 위반한다

3. 변경하거나 초기화하기 어렵다

이외에 테스트하기 어렵거나 자식 클래스를 만들기 어려운 등 

유연성이 떨어지는 문제가 있다.

4. 상태를 유지하게 될 경우 큰 문제가 발생한다

 

이런 문제를 간단하게 해결하는것이 Spring의 컨테이너와 Bean이다

 

---

위 싱글톤의 문제점에서 4번 상태 유지는

특정 클라이언트에 의존적인 필드가 있으면 안되며

특정 클라이언트가 값을 변경할 수 있는 필드가 있어서는 안됨을 의미한다

 

public class Wallet{

    private int money; //상태를 유지

    public void deposit(String name, int money){
        System.out.println("name = " + name + " momey = "+money);
        this.money = money; //문제점
    }

    public int getMoney(){
        return momey;
    }
}

지갑의 잔액을 알려주는 위 코드가 싱글톤으로 관리된다고 하자

 

ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);

Wallet person1 = ac.getBean(Wallet.class);
Wallet person2 = ac.getBean(Wallet.class);

//1번 사용자는 10만원 입금
person1.deposit("user1",100000);
//2번 사용자는 천원 입금
person2.deposit("user2",1000);

//아래 price에 출력될 값은?
int price = person1.getMoney();

애석하게도 1번 사용자의 잔액은 1000원으로 나온다

지갑이 싱글톤으로 공유되고있기 때문에 2번 사용자가 입력한 값이 출력되는 것이다

고객 개인계좌를 위와 같은 코드로 관리하는 멍청한 은행은 없겠지만

금액(상태)를 유지하고, 외부에서 값을 변경할 수 있게 만들면

위와 같이 엄청난 문제가 발생하게 된다.

 

문제의 코드를 무상태로 설계하면 아래와 같다

public class Wallet{

    public int deposit(String name, int money){
        System.out.println("name = " + name + " momey = "+money);
        return money;
    }
}

메서드를 실행하면 곧바로 매개변수로 받은 money를 반환하도록 하면 된다

값이 따로 저장되지 않기때문에 문제가 발생할 여지가 없다.