객체지향 디자인 패턴

객체지향 디자인 패턴

- 객체지향 프로그램이 복잡해지면서 객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 패턴이다

- 여러 사람이 협업할 때에는 버그를 발생시키기 쉽고 성능을 최적화 시키기도 어렵다

 

생성패턴

- 팩토리, 빌더, 싱글톤

구조패턴 (객체 결합 패턴)

- 파사드

행위 패턴 (객체 간 커뮤니케이션)

- 반복자

 

팩토리 패턴

- 상위 클래스와 하위 클래스가 있을 때, Factory Class를 사용하여 하위 클래스의 인스턴스를 생성한다

- Cat -> Animal, Dog -> Animal

public class AnimalFactory {
	static Animal create(String str) {
    	if (str.equals("Dog")) return new Dot(str);
        else if (str.equals("Cat")) return new Cat(str);
        return null;
    }
}

 

빌더 패턴

- Builder Class는 인스턴스를 생성하지 않고 빌더라는 내부 클래스를 통해 간접적으로 생성한다

 

코드

class Jacket {

	int number;
	String name;
    double size;
    
    private Jacket(int number, String name, double size) {
    	// Jacket Class init
		this.number = number;
        this.name = name;
        this.size = size;
	}
    
    // 빌더 클래스는 인스턴스를 생성자를 통해 직접 생성하지 않고,
    // 빌더라는 내부 클래스를 통해 간접적으로 생성하는 패턴 방식이다
    pulbic static class Builder {
    	int number = 0;
        String name = null;
        double size = 0;
    
        public Builder() {
            //Builder 초기화
        }

        public Builder setNumber(int number) {
            this.number = number;
            return this;
        }

        public Builder setName(String name) {
            this.name = name;
            return this;
        }

        public Builder setSize(double size) {
            this.size = size;
            return this;
        }

        public Jacket build() {
            return new Jacket(number, name, size);
        }
	}
}

public class JacketProduction {
	public static void main(String args[]) {
    	createJacket();
    }
    public static void createJacket() {
    	Jacket jacket = new Jacket.Builder().setNumber(1).setName("Nike").setSize(105).build();
		System.out.println(jacket.number +" "+ jacket.name +" "+ jacket.size);
    }
}

> 빌더 패턴을 사용하는 이유?

- 빌더 패턴이 없을 경우 인스턴스를 생성할 때 ` Jacket jacket = new Jacket(number, name, size); ` 이렇게 작성해야 한다

- 그런데 인수의 가지수가 정말 많으면, 보기도 힘들고, 순서나 인자로 주는 것이 맞는지 확인하기도 힘들어서 매우 비직관적인 코드가 된다

- 따라서, 빌더 패턴을 통해서 setXXX 형식으로 인수를 전달하면 한눈에 보기도 편하고, 이 인수가 무엇인지 파악하기도 쉽다

 

싱글톤

- 점수 기록표, 계약서 등 클래스의 객체를 하나만 만들어야 하는 경우에 사용한다

- 처음에는 초기 생성을하고, 다음부터는 생성된 인스턴스를 리턴한다

class Singletone {
	static final Singleton instance = new Singleton();
    
    private Singleton() {
    	//초기화 생성자 접근 막음
    }
    static Singleton getInstance() {
    	return instance;
    }
}

- static을 사용해서 전역으로 접근이 가능하게 해준다

- final을 사용해야한다, 그래야 인스턴스의 변형이 불가능하다

- 사전 초기화 방법 : 클래스를 로딩시에 위와 같이 인스턴스를 미리 생성한다

- 늦은 초기화 방법 : 인스턴스를 실제로 사용할 시점에 인스턴스를 생성한다. 따라서 위의 경우 처음에는 null을 주고, getInstance에서 null을 확인해서 생성하거나 기존 인스턴스를 반환한다

 

파사드 (Facade)

- 파사드는 프랑스어로 보통 건물의 출입구로 이용되는 정면 외벽 부분을 가리키는 말이다

- 파사드 패턴에서는 시스템의 복잡성을 감추고, 사용자가 시스템에 접근할 수 있는 인스턴스를 사용자에게 제공한다

 

1단계 - 인터페이스를 생성한다

public interface Coffee{
	void make();
}

 

2단계 - 그 인터페이스를 구현하는 구체적인 클래스를 생성한다

public class Americano implements Coffee {
	@Override
	public void make() {
		System.out.println("Make a cup of Americano");
	}
}

public class VanillaLatte implements Coffee {
	public void make() {
		System.out.println("Make a cup of Vanilla Latte");
	}
}

public class Cappuccino implements Coffee {
	@Override
	public void make() {
		System.out.println("Make a cup of Cappuccino");
	}
}

 

3단계 - 파사드 클래스를 생성한다

public class CoffeeMaker {
	private Americano americano;
	private VanillaLatte vanillaLatte;
	private Cappuccino cappuccino;

	public CoffeeMaker () {
		americano = new Americano();
		vanillaLatte = new VanillaLatte();
		cappuccino = new Cappuccino();
	}

	public void makeAmericano() {
		americano.make();
	}
	public void makeVanillaLatte() {
		vanillaLatte.make();
	}
	public void makeCappuccino() {
		cappuccino.make();
	}
}

 

4단계 - 다양한 종류의 형태를 만들기 위해 파사드를 사용한다

public class FacadePatternDemo {
	private static void main(String[] args) {
		CoffeeMaker coffeeMaker = new CoffeeMaker();

		coffeeMaker.makeAmericano();
		coffeeMaker.makeVanillaLatte();
		coffeeMaker.makeCappuccino();
	}
}

인터페이스로 공통된 구현을 선언해서, 구체적인 클래스에서 해당 인터페이스를 구현하고, 파사드 클래스를 만들어 준다. 이후 파사드 클래스를 통해서 정의된 메소드를 통해 사용만 하면된다

 

MVC 패턴

- 최근 애플리케이션 개발에 있어서 상당히 중요한 Model, View, Controller와 같이 세가지 부분으로 이루어져 있다

 

Model : 자료, 생성 저장 처리

View : Model로 부터 받은 자료를 여러가지 형태로 사용자에게 보여준다

Controller : 소프트웨어의 흐름을 제어한다. View와 Model 사이에서 관계를 설정해준다

- Controller는 Model이나 View가 바뀌더라도 수정없이 작동되어야 한다

 

즉, 유저가 존재하면 유저 정보는 Model에 존재하고, 해당 정보를 수정하고, 바꾸는 Method는 Model에 정의가 되어있고, Controller에서는 그 메소드를 사용만 해서 적절한 View가 제공되도록 해줘야한다. 따라서 Method내부의 수정이 일어나도 Controller는 변경이 일어나지 않는다

 

Model : setXXX, updateXXX, orderXXX

Controller : model에 정의된 메소드를 사용

View : 보여줌

 

DDD 패턴

- Domain Driven Design : 도메인 주도 설계

기존 형태는 MVC가 하나로 되어있는데 DDD에서는 도메인별로 MVC를 갖게한다. 따라서 하나의 기능 (도메인)에서 장애가 발생하더라도 그곳에 국한되고 다른 서비스에 영향을 주지 않는다. 물론 도메인 마다 따로 구현을 해야하므로 작업량이 많아질 수 있다