728x90

팩토리 패턴

팩토리 패턴은 생성패턴(Creational Pattern) 중 하나이다.
생성 패턴은 인스턴스를 만드는 절차를 추상화하는 패턴이다.
생성 패턴에 속하는 패턴들은 객체를 생성, 합성하는 방법이나 객체의 표현방법을 시스템과 분리해준다. 생성 패턴은 시스템이 상속보다 복합방법을 사용하는 방향으로 진화되어 가면서 더 중요해지고 있다.

생성 패턴에는 중요한 이슈가 2가지 있다.

  • 생성 패턴은 시스템이 어떤 Concrete Class를 사용하는지에 대한 정보를 캡슐화한다.
  • 생성 패턴은 이들 클래스의 인스턴스들이 어떻게 만들고 어떻게 결합하는지에 대한 부분을 완전히 가려준다.

이 두가지를 정리해보면, 생성 패턴을 이용하여 무엇이 생성되고, 누가, 어떻게, 언제 육하원칙 비슷하게 결정하는데에 유연성을 확보할 수 있다.

팩토리 패턴이란?

팩토리 패턴은 객체를 생성하는 인터페이스를 미리 정의하지만, 인스턴스를 만들 클래스의 결정은 서브 클래스 쪽에서 결정하는 패턴이다. 여러개의 서브 클래스를 가진 슈퍼 클래스가 있을때, 들어오는 인자에 따라서 하나의 자식클래스의 인스턴스를 반환해주는 방식이다.
팩토리 패턴은 클래스의 인스턴스를 만드는 시점 자체를 서브 클래스로 미루는 것이다.

활용성

  • 어떤 클래스가 자신이 생성해야 하는 객체의 클래스를 예측할 수 없을 때
  • 생성할 객체를 기술하는 책임을 자신의 서브클래스가 지정했으면 할 때

Java Example

Figure.java

public interface Figure {
    void draw();
}

Circle.java

public class Circle implements Figure {

    @Override
    public void draw() {
        System.out.println("Circle의 draw 메소드");
    }

}

Rectangle.java

public class Rectangle implements Figure {

    @Override
    public void draw() {
        System.out.println("Rectangle의 draw 메소드");
    }

}

Square.java

public class Square implements Figure {

    @Override
    public void draw() {
        System.out.println("Square의 draw 메소드");
    }

}

FigureFactory

public class FigureFactory {
    public Figure getFigure(String figureType) {
        if(figureType == null) {
            return null;
        }
        if(figureType.equalsIgnoreCase("CIRCLE") {
            return new Circle();
        } else if (figureType.equalsIgnoreCase("RECTANGLE") {
            return new Rectangle();
        } else if (figureType.equalsIgnoreCase("SQUARE") {
            return new Square();
        }

        return null;
    }

}

여기서 equalsIgnoreCase()는 앞에 매개변수인 figureType의 문자열과 대소문자 구분을 하지않고 뒤의 문자열과 일치하면 true를 반환해준다.

FactoryPattern.java

public class FactoryPattern {
    public static void main(String[] args) {
        FigureFactory figureFactory = new FigureFactory();

        Figure fig1 = figureFactory.getFigure("CIRCLE");

        // Circle의 draw 메소드 호출
        fig1.draw();

        Figure fig2= figureFactory.getFigure("RECTANGLE");

        // Rectangle의 draw 메소드 호출
        fig2.draw();

        Figure fig3 = figureFactory.getFigure("SQUARE");

        // Square의 draw 메소드 호출
        fig3.draw();
    }
}

팩토리 패턴의 장점

  • 팩토리 패턴은 클라이언트 코드로부터 서브 클래스의 인스턴스화를 제거하여 서로 간의 종속성을 낮추고, 결합도를 느슨하게 하며(Loosely Coupled), 확장을 쉽게 한다.

  • 팩토리 패턴은 클라이언트와 구현 객체들 사이에 추상화를 제공한다.

팩토리 패턴의 단점

  • 새로 생성할 객체가 늘어날 때마다, Factory 클래스에 추가해야 되기 때문에 클래스가 많아짐.
728x90
728x90

@Resource, @Autowired, @Inject 차이점 정리

세 개의 어노테이션은 컨테이너에 생성된 빈(Bean) 객체를 자동으로 주입받을 수 있도록 해주는 어노테이션들이다. 주의할 점은 Bean 객체가 생성될 때 어노테이션을 스캔해서 자동 주입해준다. 일반적인 방법으로 해당 클래스의 instance를 new해서 생성하면 어노테이션은 작동하지 않는다.
그냥 Bean 설정 파일에서 하나하나 ref="다른bean" 을 생략할수 있다. 설정파일에서 Bean을 등록하지 않고 어노테이션을 통해(@Bean) 등록할 수도 있는데 원리는 같다.

@Resource

Java에서 지원하는 어노테이션이며 특정 프레임워크에 종속적이지 않다.
순서는 아래와 같다.

이름 > 타입 > @Qualifier > 성공

name 속성의 이름을 기준으로 찾는다. 없으면 타입, 없으면 @Qualifier 어노테이션의 유무를 찾고 그 어노테이션이 붙은 속성에 의존성을 주입한다.

context:annotation-config/ 구문을 꼭 xml에 추가해야한다.

사용할 수 있는 위치
멤버변수, setter메소드

@Autowired

Spring에서 지원하는 어노테이션
찾는 순서

타입 > 이름 > @Qualifier > 성공

@Autowired는 주입하려고 하는 객체의 타입이 일치하는지를 찾고 객체를 자동으로 주입한다.
만약 타입이 존재하지 않는다면 @Autowired에 위치한 속성명이 일치하는 bean을 컨테이너에서 찾는다. 그리고 이름이 없을 경우 @Qualifier 어노테이션의 유무를 찾아 그 어노테이션이 붙은 속성에 의존성을 주입해준다.

context:annotation-config/ 구문을 꼭 xml에 추가해야한다.

사용할 수 있는 위치
생성자, 멤버변수, setter 메소드에 적용이 가능함.

스프링 4.3버전 이후부터 생성자가 1개일경우 @Autowired 어노테이션을 생략이 가능하다.

@Inject

Java에서 지원하는 어노테이션이다. 특정 프레임워크에 종속적이지 않다.
찾는 순서

타입 > @Qualifier > 이름 > 실패

@Autowired와 동일하게 작동은 하지만 찾는 순서가 다르다.
@Inject를 사용하기 위해선 maven이나 gradle에 javax 라이브러리 의존성을 추가해야한다.

사용할 수 있는 위치
멤버변수, setter 메소드, 생성자, 일반 메소드에 적용 가능

@Qualifier

만약에 타입이 동일한 bean객체가 여러개가 있을시에 Spring이 Exception을 일으킨다.
스프링이 어떤 bean을 어떤것에 주입해야될지 모르기 때문에 스프링 컨테이너를 초기화하면서 에러를 발생시킨다.

  • @Autowired의 주입대상이 한개여야하는데 실제로 두개 이상의 Bean이 존재하여 주입할때 객체를 선택할 수 없다.
  • 단, @Autowired가 적용된 필드나 설정 메소드의 property 이름과 같은 이름을 가진 Bean객체가 존재할 경우에는 이름이 같은 Bean 객체를 주입받는다.

Exception
@Qualifier에 지정한 Bean 한정자 값을 갖는 Bean이 존재하지 않으면 Exception 발생함.

정리

@Resource @Autowired @Inject
범용 Java에서 지원 Spring 전용 Java에서 지원
연결방식 이름으로 매핑 타입에 맞춰서 연결 타입에 맞춰서 연결
728x90

'Spring' 카테고리의 다른 글

Spring -> Spring Boot 마이그레이션  (0) 2022.08.05
[Spring] MockMvc Bean 주입 에러  (0) 2022.08.04
[Spring] Spring Security  (0) 2022.08.03
Spring Test MockMvc 한글 깨짐 처리  (0) 2022.08.03
728x90

싱글톤패턴(Singleton Pattern)

싱글톤패턴

애플리케이션이 시작될 때 어떤 클래스가 최초 한번만 메모리를 할당하고 그 메모리에 인스턴스를 만들어 사용하는 디자인패턴이다.
생성자가 여러번 호출이 되더라도 실제로 생성되는 객체는 하나뿐이고, 최초로 생성된 이후에 호출된 생성자는 생성된 최초 객체를 반환한다.
그래서 생성자를 private로 선언하여 getInstance()로 받아서 사용한다.

싱글톤 패턴은 단 하나의 인스턴스를 생성해 사용하는 디자인 패턴이다.

이말은 인스턴스가 필요할 때마다 똑같은 인스턴스를 new해서 생성하는 것이 아닌 기존에 존재하는 인스턴스를 사용하게 하는것이다.


싱글톤패턴을 사용하는 이유

고정된 메모리 영역을 얻으면서 한번의 new로 인스턴스를 사용하기 때문에 메모리 낭비를 방지할 수 있다. 또한 싱글톤으로 만들어진 클래스의 인스턴스는 전역 인스턴스이기 때문에 다른 클래스의 인스턴스들이 데이터를 공유하기가 쉽다.
DBCP(DataBase Connection Pool)처럼 공통된 객체를 여러개 생성해서 사용해야 할 경우에 많이 쓴다.

  • 인스턴스가 절대적으로 한개만 존재하는 것을 암시할때 사용
  • 두번째 호출부터는 객체의 로딩 시간이 현저하게 줄어들어 성능이 좋아짐

싱글톤 패턴의 문제점

싱글톤에 해당하는 인스턴스가 너무 많은 일을 혼자 처리하거나 많은 데이터를 공유할 경우에 다른 클래스의 인스턴스들 간의 결합도가 높아져서 객체지향 설계 원칙인 개방-폐쇄 원칙에 위배된다.
그리고 멀티스레드 환경에서 문제가 생길 가능성이 짙다.

고전적인 방식

public class Singleton {
    private static Singleton instance;    

    private Singleton(){
        //생성자
    }

    public static Singleton getInstance(){
        if(instance == null){ // 오류 1. : 스레드가 동시에 접근했을 시 문제 발생
            instance = new Singleton(); // 2. 쓰레드가 동시 접근시 인스턴스 여러번 생성
        }
        return instance;
    }
}

보통의 Singleton 패턴 방식이다. private static으로 자기자신의 클래스를 인스턴스로 가지고 있고 getInstance() 로 대상 인스턴스를 초기화 후 반환해주는 패턴이다. 그냥 싱글스레드로 봤을때는 문제가 없을 수 있다. 하지만 멀티스레드라면 문제가 발생한다.
if(instance == null) 이 지점이 A 스레드에서 진행된 뒤에 제어권이 B 스레드로 넘어간 경우에는 또 다시 B에서 if(instance == null)이 수행되니까 if문이 다르지만 2번이 수행된다. 그래서 instance = new Singleton(); 이 생성된다. 여기서 또 다시 A 스레드로 제어권이 넘어가면 A 스레드에서 또한번 instance = new Singleton();이 수행된다. 그렇기 때문에 2개의 인스턴스가 생성되는 경우가 생기게된다.

A 스레드 : if(instance==null) -- true
B 스레드 : if(instance==null) -- true
A 스레드 : instance = new Singleton(); 인스턴스A 생성됨
B 스레드 : instance = new Singleton(); 인스턴스B 생성됨

synchronized 키워드를 사용한 Singleton 패턴

public class Singleton{
    private static Singleton instance;

    private Singleton(){

    }

    public static synchronized Singleton getInstance(){
        if(instance == null){
            instance = new Singleton();
        }
        return instance;
    }
}

synchronized를 사용하게 되면 하나의 스레드가 대상 메소드를 호출하여 시작~종료 까지 다른 스레드가 접근하지 못하도록 lock을 걸기 때문에 getInstance()에 synchronized를 사용하면 멀티 스레드 환경에서 동시접근하여 중복으로 인스턴스를 생성하는 문제를 해결할 수 있다.
그렇지만 synchronized getInstance() 의 경우 반환을 받을때 마다 스레드 동기화때문에 불필요하게 lock이 걸리게 됨 -> 비용낭비가 ↑↑↑
초기화 문제에 synchronized 를 사용했지만 초기화가 완료되고 난 후 부터는 불필요하게 lock을 걸기때문에 중복제거라는 메리트를 제외하면 다른 역할이 좋지가 않다.

이 성능 저하로 인해 완화시키기 위하여 다음과 같이 변경한다.

public class Singleton {

    private volatile static Singleton instance;

    private Singleton(){

    }

    public static Singleton getInstance(){

        if(instance == null){
            synchronized (Singleton.class) {
                if(instance == null)
                    instance = new Singleton();
            }

        }
        return instance;
    }
}

getInstance()에서 바로 synchronized를 사용하는 것이 아니라 if(instance == null)로 인스턴스가 존재하는지를 체크하고 두번째if(instance == null)에서 체크할 때, 동기화 시켜 인스턴스를 생성한다. synchronized 블럭을 처음 생성할 때 빼고는 수행하지 않기때문에 성능저하는 완화되었다.

volatile 키워드를 이용하는 경우 인스턴스는 CPU캐시에서 변수를 참조하지 않고 메인 메모리에서 변수를 참조한다. 그래서 reorder문제가 발생하지 않는다.

reorder란, 최적화를 위해 컴파일러나 JVM이 프로그램의 처리 순서를 바꾸는 것을 말한다.
프로그램의 수행 능력을 높이기 위해 널리 사용되고 있지만, 그 사실을 프로그래머가 의식하기는 어렵다. 
실제 싱글 쓰레드 프로그램에서는 reorder가 이뤄지고 있는지 판단할 수 없다.
reorder시에 예기치 못한 작동을 막기 위한 제약이 따르기 때문이다.
(사실 싱글 쓰레드 프로그램에서는 reorder로 인한 동시성 문제가 일어나지 않는다.)
그러나 멀티 쓰레드 프로그램에서는 reorder가 원인이 되어 예기치 못한 작동을 하는 경우가 있다.

이것도 완벽한 방법은 아니기에 아래의 방법을 사용한다.

Holder에 의한 초기화를 사용한 Singleton 패턴

public class Singleton{
    private Singleton(){

    }

    private static class Holder{
        public static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance(){
        return Holder.INSTANCE;
    }
}

직접적으로 동기화 문제에 대해서 문제를 회피하고자 다른 위의 방법들을 사용했지만 그만큼 복잡해졌었고 또 다른 오류가 발생할 수 있는것들을 확인하였다.
이 방법은 JVM클래스가 초기화 과정에서 보장되는 원자적 특성을 이용해 싱글톤 패턴의 초기화 문제에 대한 책임을 JVM에 떠넘긴다.
Holder안에 선언한 인스턴스가 static이기 때문에 로딩된 시점에 한번만 호출될 것이고 final을 사용하여 값이 재할당되는것을 막은 방법이다.

가장 많이 사용하고 일반적인 Singleton Pattern 사용 방법이다.

728x90

'Java' 카테고리의 다른 글

[Java] Enum  (0) 2022.08.03
[Java] Optional  (0) 2022.08.03
Java Stream API  (0) 2022.08.03
CallByValue, CallByReference 비교  (0) 2022.08.03
728x90

Spring Test MockMvc의 한글 깨짐 처리

스프링에서 테스트 코드를 작성할 때 MockMvc를 흔히 사용한다.

대략 아래와 같이 설정하고 사용한다.

변경일자 2022-04-19 수정
MockMvc를 보통 테스트코드를 작성할 때 사용할텐데,

@WebMvcTest를 사용해서 mvc를 위한 테스트를 만들 수 있다.

//@SpringBootTest  
@WebMvcTest(ApiController.class)  
public class ApiControllerTest {  

    private MockMvc mockMvc;  

    @Autowired  
    private WebApplicationContext ctx;  

    @BeforeEach  
    public void setup() {  
        this.mockMvc = MockMvcBuilders.webAppContextSetup(ctx)  
                .alwaysDo(print())  
                .build();  
    }  

    @Test  
    public void aaa() throws Exception {  
        String keyword = "sports";  

        MvcResult result = this.mockMvc  
                .perform(  
                        get("/api/search/" + keyword)  
                )  
                .andExpect(status().isOk());  
    }  
}  

위의 테스트 코드에서는 한글이 없으므로 아무 문제가 없는데, 아래와 같이 한글을 사용하면 깨진 한글이 Controller에 유입될 수 있으며, 결국 원하는 대로 동작하지 않게 된다.

    @Test  
    public void aaa() throws Exception {  
        String keyword = "스포츠";  // 한글 사용  

        MvcResult result = this.mockMvc  
                .perform(get("/api/search/" + keyword))  
                .andExpect(status().isOk());  
    }  

이 문제는 `MockMvc`를 설정할 때 `CharacterEncodingFilter`를 추가해주면 쉽게 해결할 수 있다.

    @Before  
    public void setup() {  
        this.mockMvc = MockMvcBuilders.webAppContextSetup(wac)  
                .addFilters(new CharacterEncodingFilter("UTF-8", true))  // 필터 추가  
                .alwaysDo(print())  
                .build();  
    }  
728x90

'Spring' 카테고리의 다른 글

Spring -> Spring Boot 마이그레이션  (0) 2022.08.05
[Spring] MockMvc Bean 주입 에러  (0) 2022.08.04
[Spring] Spring Security  (0) 2022.08.03
의존성 주입 어노테이션 정리  (0) 2022.08.03
728x90

Call By Value(값에 의한 호출)

call by value 는 가장 일반적인 함수 호출형태로 값을 복사하는 것이다.

예시

public class CallByValue{
    public static void swap(int x, int y){
        int temp = x;
        x = y;
        y = temp;
    }

    public static void main(String[] args){
        int a = 10;
        int b = 20;

        System.out.println("swap() 호출 전 : a = " + a + ", b = " + b);

        swap(a, b);
        System.out.println("swap() 호출 후 : a = " + a + ", b = " + b);
    }
}

결과는 아래와 같다

swap() 호출 전 : a = 10, b = 20
swap() 호출 후 : a = 10, b = 20

이유는 swap() 메서드 호출 시 사용한 인자 a, b와 swap() 메서드내의 매개변수 x, y는 서로 다르다.
memory

main()에서 선언 된 변수 a와 b가 각각 메모리의 0x0001번지와 0x0005번지에 할당 되었다고 가정 할당 된 메모리 변수에는 각각 10과 20의 값이 저장된다. 이후, swap() 메서드 호출 시에 사용한 인자 a와 b는 할당 된 메모리 주소가 아닌 메모리에 담겨져 있던 값만이 복사되어 swap() 메서드 내부의 매개변수 x와 y의 메모리 주소에 담겨지게 된다. 당연하게도 swap() 메서드가 수행하는 동안 사용되는 변수들은 main()에 존재하는 a와 b가 아닌 swap() 내부에 새로 생성 된 x와 y이기 때문에 메서드 수행 후에도 결과 값에 변화가 없다.

Call By Value는 메서드 호출 시에 사용되는 인자의 메모리에 저장되어 있는 값(value)을
복사하여 보낸다.

Call By Reference

Call by reference는 메서드 호출 시에 사용되는 인자가, 값이 아닌 주소(Address)를 넘겨줌으로써, 주소를 참조(Reference)하여 데이터를 변경할 수 있다.

public class CallByReference{
    int value;

    CallByReference(int value){
        this.value = value;
    }

    public static void swap(CallByReference x, CallByReference y){
        int temp = x.value;
        x.value = y.value;
        y.value = temp;
    }

    public static void main(String[] args){
        CallByReference a = new CallByReference(10);
        CallByReference b = new CallByReference(20);

        System.out.println("swap() 호출 전 : a = " + a.value + ", b = " + b.value);

        swap(a, b);

        System.out.println("swap() 호출 후 : a = " + a.value + ", b = " + b.value);
    }
}

결과

swap() 호출 전 : a = 10, b = 20
swap() 호출 후 : a = 20, b = 10

memory2

main()에서 선언 된 CallByReference 타입의 변수 a와 b는 각각 객체를 생성하여 0x0001번지와 0x0005번지에 저장된 10과 20의 주소 값을 저장하게 된다. 이후, swap() 메서드 호출 시에 인자 a와 b는 메모리에 저장 된 주소 값을 복사하여 매개변수 x와 y의 메모리에 저장한다. 결국 swap() 메서드는 10과 20이 저장 된 0x0001번지와 0x0005번지의 주소를 참조하여 연산하기 때문에, 연산 결과에 따라 원본 데이터가 변하게 된다. main()에서 선언 된 변수 a와 b는 각각 0x0001번지와 0x0005번지를 가리키고 있기 때문에 변한 데이터를 불러들여 결과 값이 변하게 된다.

Call By Reference는 메서드 호출 시 사용되는 인자 값의 메모리에 저장되어 있는 주소(Address)를 복사하여 보낸다.
728x90

'Java' 카테고리의 다른 글

[Java] Enum  (0) 2022.08.03
[Java] Optional  (0) 2022.08.03
Java Stream API  (0) 2022.08.03
[Java] 디자인패턴 - 싱글톤 패턴  (0) 2022.08.03
728x90

WAS(Web Application Server)

1. WAS란?

웹 브라우저와 같은 클라이언트로부터 웹 서버가 요청을 받으면 애플리케이션에
대한 로직을 실행하여 웹 서버로 다시 반환해주는 소프트웨어
웹 서버와 DBMS 사이에서 동작하는 미들웨어로서 컨테이너 기반으로 동작한다.

2. WEB서버와 WAS의 동작 과정

image1

3. WEB 서버와 WAS의 차이점

  • 요청을 받아 처리하는 컨텐츠의 차이
    • 웹서버의 경우 : 정적인 컨텐츠(HTML, CSS, IMAGE 등)을 요청받아 처리
    • WAS의 경우 동적인 컨텐츠(JSP, ASP, PHP 등)를 요청받아 처리

4. WEB서버와 WAS를 나눠야하는 이유

WAS의 경우 웹서버 + 웹 컨테이너의 개념이라 웹 서버가 없더라도 웹 서버의 역할을 동시에 수행이 가능하다.
그래서 웹 서버를 사용하지 않더라도 웹 서비스를 할 수 있지만 웹 서버와 WAS를 나눠서 사용한다.

이유
  1. 데이터 처리 방식

    웹 서버는 정적인 컨텐츠를 처리하고 WAS는 동적인 컨텐츠를 처리한다.

  2. 보안

    사용자들에게 WAS는 공개될 필요가 없음

    위동작에서 사용자에게 요청은 웹 서버가 받고 그 요청을 WAS에 전달한다.

    그리고 WAS의 경우 DB서버에 대한 접속 정보가 있기 때문에 외부로 노출될 경우 보안상 문제를 야기할 수 있다.
    그래서 웹 서버의 경우 DMZ구간에 위치하고 WAS는 내부망에 위치시켜 보안을 유지할 수 있다.

DMZ란? - 내·외부 네트워크 구간 사이에 위치한 중간지점으로, 침입차단시스템 등으로 접근 제한
         등을 수행하지만 외부 네트워크에서 직접 접근이 가능한 영역을 뜻합니다.
728x90

+ Recent posts