여러 디자인 패턴에 관해 ARABOZA

디자인 패턴이란?

프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 ‘규약’ 형태로 만들어 놓은 것을 의미

 

---

목차

1. 싱글톤 패턴
2. 팩토리 패턴
3. 전략 패턴
4. 옵저버 패턴
5. 프록시 패턴과 프록시 서버
6. 이터레이터 패턴
7. 노출모듈 패턴
8. MVC 패턴
9. MVP 패턴
10. MVVM 패턴

---

1. 싱글톤 패턴

• 싱글톤 패턴이란
  • App이 실행할 때, 최초 한번만 메모리에 할당하여 해당 인스턴스를 사용하는 디자인 패턴
  • 즉 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴
  • 객체를 미리 생성해두고 가져다 쓰는 방법
• 장점 :
  • 인스턴스를 생성할 때 드는 비용이 줄어든다
  • 최초 한번의 new 연산자를 통해서 고정된 메모리 영역을 사용하기 때문에 추후 해당 객체에 접근할 때 메모리 낭비를 방지할 수 있다
  • 다른 클래스간 데이터 공유가 쉽다

public class Singleton {
    private static Singleton instance = new Singleton();
    
    private Singleton() {
        // 생성자는 외부에서 호출못하게 private 으로 지정해야 한다.
    }
    public static Singleton getInstance() { //getInstance를 사용해서 새로운 Singleton 객체 사용을 막는다
        return instance;
    }
    public void say() {
        System.out.println("hello");
    }
}

전역으로 사용되는 인스턴스 이기에, 다른 클래스의 인스턴스들이 접근하여 사용 가능

• 단점 :
  • 모듈간의 결합이 강해진다(의존성이 높아진다)
  • 구체화 클래스에 의존도가 높아진다 -> DIP를 위반 -> OCP원칙을 위반할 수 있다
  • 싱글톤 패턴을 구현하는 코드 자체가 많이 필요하다
  • 자원을 공유하고 있기에 테스트 하기 어렵다 -> 격리된 환경에서 테스트가 수행될 수 있게 매번 인스턴스 상태를 초기화 필요
• 참고 사이트
  • 우테코-싱글톤(Singleton) 패턴이란? - SOLID 객체지향 설계

2. 팩토리 패턴

• 팩토리 패턴이란
  • 객체의 사용 부분과 생성 부분을 따로 떼어 내어 별도의 객체로서 생성,사용 하는 것
    • (객체 생성을 대신 수행해주는 공장이라고 생각하자)
  • 상속 관계에 있는 두 클래스에서, 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용 결정
• 예 : 상위 클래스에서 자동차에 필요한 필수 요소만 가지고, 하위 클래스에서는 각 자동차에 대한 구체적인 애용이 결정됨 (추상화)
• 장점 :
  • 객체 생성부를 캡슐화하여, 객체 간의 결합도를 낮출 수 있다 (느슨한 결합->구현체 클래스에 의존하지 않음)
  • OCP (개방 폐쇄 원칙)를 따른다
    • 클래스 내부 코드를 직접 수정하지 않아도 기능 확장/변경이 가능
  • SRP (단일 책임 원칙)를 따른다
    • 클라이언트가 특정 객체의 생성을 직접 생성하지 않고 생성 역할을 하는 클래스를 만들어 그 클래스에게 위임
• 단점 :
  • 새로 생성할 객체가 늘어날 때마다, Factory 클래스에 추가해야 되기 때문에 클래스가 많아진다
• 참고 사이트
  • Factory Method Pattern 팩토리 메소드 패턴
  • 팩토리 메소드 패턴(Factory Method Pattern)

3. 전략 패턴

• 전략 패턴이란
  • 정책 패턴이라고도 한다
  • 특정 객체의 행위를 직접 구현하지 않고, 캡슐화된 객체로 구현하여, 컨텍스트 내에서 상호 교체가 가능하도록 만드는 패턴
• 예 : 어떤 물건을 살 때 결제수단은 여러 가지이고, 그중 어떤 것을 선택해도 성공적으로 결제가 된다
• 장점 :
  • 팩토리 패턴과 유사하게 공통 로직이 부모 클래스에 있지 않고 Context 라는 별도의 클래스에 존재하기 때문에 구현체들에 대한 영향도가 적음
  • 쉽게 변하지 않는 상위 인터페이스(클래스)에 의존하기 때문에 확장/삭제에 용이하다
• 단점 :
  • 로직이 늘어날 때 마다 구현체 클래스가 늘어난다
  • 앱에 들어가는 모든 전략을 알고 있어야 해서, 한번 전략을 조립하면 변경하기가 힘들다
• 참고 사이트
  • 저는 전략 패턴이 처음이라니까요?

4. 옵저버 패턴

• 옵저버 패턴이란
  • 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 발생하면 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴
  • 특정 변화에 따른 동작이 미리 정의되어 있고, 변화가 발생하면 이러한 동작이 즉각 수행된다.
  • 이벤트의 처리를 효율적으로 할 수 있다
• 장점 :
  • 변경 사항이 생겨도 무난히 처리할 수 있는 유연한 객체지향 시스템을 구축할 수 있다
  • OCP (개방 폐쇄 원칙)를 지킬 수 있다
• 단점 :
  • 알림이 가는 순서를 보장할 수 없다
  • 옵저버와 알림을 받는 Subject간의 관계가 잘 정의되지 않으면 원치 않는 동작이 발생할 확률이 높다
• 참고 사이트
  • iOS 옵저버 패턴

5. 프록시 패턴과 프록시 서버

• 프록시 패턴이란
  • 대상 객체에 접근하기 전에 그 접근에 대한 흐름을 가로채, 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴
• 프록시 서버란
  • 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다
    • 클라이언트 -> 웹 서버 로의 요청이 클라이언트 -> 프록시 서버 -> 웹서버로, 중간에 하나의 계층이 더 생긴다
• 장점 :
  • 사이즈가 큰 객체가 로딩되기 전에도 프록시를 통해 참조를 할 수 있다(전처리 및 후처리 사용 용이)
  • 특정 메서드에 대한 보안이 좋다. (B가 C에게 요청을 하여 A는 C가 무슨 일이 일어나는지 정확히 알기 힘들다는 점)
• 단점 :
  • 가독성이 떨어진다. (A->B->C라는 구조로 누군가 거쳐가야 한다는 점 이런 경우가 많아지면 가독성이 떨어질 우려된다)
• 참고 사이트
• 프록시 서버란 무엇인가? (Proxy Server)
• 프록시 패턴 셜명 및 장단점

6. 이터레이터 패턴

• 이터레이터 패턴이란
  • 각기 다른 자료구조 구현체(array,linkedList,set)가 iterator라는 하나의 인터페이스를 통해 순회할 수 있도록 해주는 디자인 패턴
  • 컬렉션 구현 방법을 노출시키지 않으면서도 그 집합체안에 들어있는 모든 항목에 접근할 수 있게 해 주는 방법을 제공해 주는 패턴
• 장점 :
  • 내부적인 구현 방법을 외부로 노출시키지 않으면서도 집합체에 있는 모든 항목에 일일이 접근할 수 있다
• 단점 :
  • 간단한 컬랙션인 경우, 이터레이터를 사용하는 것은 일부 특수 컬렉션의 요소를 직접 탐색하는 것 보다 덜 효율적일 수 있다
• 참고 사이트
  • [Design Pattern] 이터레이터 패턴 (iterator pattern)

7. 노출모듈 패턴

• 노출모듈 패턴이란
  • 즉시 실행 함수를 통해 private,public같은 접근 제어자를 만드는 패턴
    • 즉시 실행 함수 : 함수를 정의 하자마자 바로 호출하는 함수. 초기화 코드, 라이브러리 내 전역 변수의 충돌 방지 등에 사용한다
  • JavaScript는 언어 레벨에서 접근 제어자가 존재하지 않고, 전역 변위에서 스크립트가 실행된다

 

const rmp = (() => {
          const a = 1;
          const b = () => 2;
      
          const public = {
            c: 2,
            d: () => 3,
          };
          return public;
      })();
      
      console.log(rmp);
      console.log(rmp.a);
      // { c: 2, d: [Function: d] }
      // undefined

a와 b는 다른 모듈에서 접근할 수 없는 private 범위를 가진다
c와 d는 다른 모듈에서도 사용할 수 있는 public 범위를 가지게 된다
이 원리를 기반으로 만든 자바스크립트 모듈 방식이 바로 CJS(CommonJS)입니다.

8. MVC 패턴

정의

• Model, View, Controller로 어플리케이션의 구성 요소를 세 가지 역할로 구분하고, 각 기능에 집중하는 디자인 패턴

상세 내용

• 모델 (Model) : 어플리케이션을 구성하는 DB,정보,상수,변수등의 데이터 계층
  • 비즈니스 로직을 처리한다
  • 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다
  • View나 Controller에 대해서 어떤 정보도 알지 말아야 한다
  • 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다
• 뷰 (View) :사용자에게 보여지는 화면,UI등을 말한다
  • 데이터 및 객체의 입력, 그리고 보여주는 출력을 담당한다
  • Model이 가지고 있는 정보를 따로 저장해서는 안 된다
  • Model이나 Controller와 같이 다른 구성요소들을 몰라야 된다
  • 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야만 한다
• 컨트롤러 (Controller) : 데이터(Model)와 UI(View) 요소들을 잇는 다리 역할의 레이어
  • 사용자의 요청에 맞는 이벤트 등, 메인 로직을 담당한다
  • Model이나 View의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려준다
  • Model이나 View에 대해서 알고 있어야 한다 (모델과 뷰의 생명주기도 관리한다)
• 장점 :
  • 서로 분리되어 각각의 역할만 담당함으로써 유지보수,확장성,유연성이 증가됨
  • 중복 코딩이라는 문제점 또한 사라진다
• 단점 :
  • View와 Model 사이의 의존성이 높다 -> 어플리케이션이 커질수록 복잡해지고 유지 보수가 어렵다

Repository, Service는 무엇인가?
위처럼 MVC 패턴을 이용하면 비즈니스 로직과 뷰는 분리가 된다
하지만, Controller에서는 HTTP 연결을 담당하는 컨트롤러 로직이 있기 때문에
컨트롤러가 너무 많은 일을 담당하게 된다.
위 문제점 때문에 Service, Repository 계층을 따로 만들어서 Controller는 컨트롤러 로직에만 집중할 수 있게한다.
그렇게 분리된 Repository, Service , DTO ,DAO 등은 사실상 Controller 레이어에 속한다!

참고 자료

• [Spring MVC] Spring MVC 패턴
• [개발자 면접준비]#1. MVC패턴이란

9. MVP 패턴

정의

• MVC 패턴으로부터 파생되었으며 MVC의 Controller 가 Presenter로 교체된 패턴

상세 내용

• Presenter
  • View에서 요청한 정보로 Model을 가공하여 View에 전달해 주는 부분. View와 Model을 붙여주는 접착제 역할을 한다(컨트롤러와 유사)
  • Presenter는 기존 MVC 패턴의 단점이었던 Model과 View 사이의 높은 의존성을 해소하기 위하여 등장
• 장점 :
  • View와 Model 사이에 Presenter라는 연결 부분을 두어 MVC 패턴의 단점인 의존성을 보완했다
    • MVC 패턴의 단점인 View와 Model사이의 의존성이 없다
• 단점 :
  • View와 Presenter사이는 1대1관계를 유지해야해서 의존성이 높고, 앱이 커질수록 이 의존성은 더 강해진다

참고 자료

• [디자인패턴] MVC, MVP, MVVM 비교
• MVC, MVP, MVVM 패턴의 특징

10. MVVM 패턴

정의

MVC의 C에 해당하는 컨트롤러가 뷰 모델(View Model)로 바뀐 패턴

상세 내용

• View Model(VM)
  • View Model은 View를 더 추상화한 계층
  • View 상태를 유지 및 변화시키고, View에 대한 작업의 결과로 Model을 조작한다
  • View에서 발생되는 이벤트를 전달 하는데 도움이 되는 메서드, 명령, 또는 다른 속성들을 노출하는 역할을 한다
• MVVM은 View와 ViewModel사이의 관계가 1대N으로 되어있다
• 장점 :
  • View와 View Model 사이 양방향 데이터 바인딩을 지원한다
  • View와 Model 사이의 의존성이 없다. View와 View Model 사이의 의존성이 없다
  • UI를 별도의 코드 수정 없이 재사용할 수 있고 단위 테스팅하기 쉽다
• 단점 :
  • View Model의 설계가 어려움