싱글톤 패턴
하나의 클래스에 하나의 인스턴스만 가지는 패턴
DB 커넥션풀에 사용됨
장점
- 한번의 new를 통한 인스턴스 생성으로 메모리 낭비를 방지한다.
- 인스턴스는 전역이기에 다른 클래스의 인스턴스들이 데이터 공유 가능
단점
- 싱글톤은 인스턴스를 하나 만들어두고 이를 사용하는 것이기에 인스턴스에 변경이 일어난다면 이를 참조하고 있는 다른 인스턴스에도 영향을 줌. -> 결합도가 높아짐
- TDD를 진행할 때 테스트가 독립적이지 않는 문제 발생
팩토리 패턴
여러개의 서브 클래스를 가진 슈퍼 클래스가 있을 때 인풋에 따라 하나의 자식 클래스의 인스턴스를 리턴해주는 방식. 클래스의 인스턴스를 만드는 시점을 서브 클래스로 미룬다.
// 주어지는 인풋에 따라 인스턴스를 리턴해준다.
Coffee coffee = CoffeeFactory.createCoffe(COFFEE.AMERICANO);장점
- 확장에 열려있다.
단점
- 많은 클래스를 정의해야 해서 코드량이 증가한다.
전략패턴
비슷한 동작을 하지만, 다르게 구현되어 있는 행위(전략)들을 인터페이스를 구현하는 클래스로 구현하여 전략만 변경하여 유연한 확장을 만드는 패턴.
전략 변경을 통해 동적으로 객체의 동작이 바뀌도록 할 수 있다.
shop.pay(new KAKAO());
shop.pay(new TOSS());장점
- 런타임시 객체 내부에서 사용되는 알고리즘을 변경할 수 있다.
- 구체적인 구현 정보를 분리할 수 있다. -> 개방 폐쇄 원칙을 만족
단점
- 무분별한 인터페이스 사용으로 프로그램이 복잡해질 수 있다.
옵저버패턴
객체의 상태 변화를 관찰하다 변화가 있을 때마다 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴
프록시 패턴
어떤 객체를 직접적으로 참조하는 것이 아닌, 대리 (proxy) 객체를 통해 대상 객체에 접근하는 방식
장점
- 사이즈가 큰 객체가 전부 로딩되기 전에도 프록시를 통해 참조할 수 있다.
- 실제 객체가 사용되어야 하는 시점까지 객체 생성을 미룰 수 있다.
단점
- 빈번한 객체 생성이 필요한 경우 성능 저하 우려
MVC | MVP | MVVM 패턴
MVC
Model, View, Controller 로 이루어진 디자인 패턴
- Model: DB와 연관되어 있는 데이터, 상수나 변수
- View: 사용자에게 보여지는 화면
- Controller: 모델과 뷰를 잇는 로직을 담당
MVP
Controller가 Presenter로 교체됨
View와 Presenter가 일대일로 결합
MVVM
Mode, View, ViewModel 로 이루어진 디자인 패턴
ViewModel은 커맨드와 데이터바인딩을 가짐
- 커멘드 : 여러 요소에 대한 처리를 하나의 액션으로 처리할 수 있는 기법
사용자의 Action은 View를 통해 ViewModel로 전달되고 Model과 데이터를 주고 받은 후 Data Binding을 통해 화면에 뿌린다.
flux 패턴
데이터 흐름을 일관성 있게 관리함으로써 대규모 애플리케이션에서 프로그램의 예측 가능성을 높여준다.
기존의 MVC 패턴은 Model의 데이터 변경으로 View 데이터가 변경될 수 있고, View 를 통해 데이터를 입력해 Model을 업데이트 할 수 있다. 즉 양방향 데이터 흐름을 가지게 되고 대규모 애플리케이션에서는 복잡해지게 된다.
사용자가 Action을 발생시키면 이는 Dispatcher에 들어와 Store가 등록해놓은 적절한 콜백 함수가 실행됨. 콜백함수로 데이터 변경이 발생하면 View에게 변경을 알려주고 View에서는 Store 데이터를 가져와 화면에 보여준다.
리엑트에서 쓰이는거 같움!
