면접을 위한 CS 전공지식 노트 - 1장-2

이전 글에 이어서 디자인 패턴을 간단하게 정리한다.

 

팩토리 패턴

1. 특징
   • 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴
   • 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴
2.  장점
   • 상위 클래스와 하위 클래스가 분리되기 때문에 느슨한 결합을 가진다.
   • 상위 클래스에서는 인스턴스 생성 방식에 대해 전혀 알 필요가 없기 때문에 더 많은 유연성을 가짐
   • 객체 생성 로직이 따로 떼어져 있기 때문에 코드를 리팩터링 하더라도 한 곳만 고칠 수 있으므로 유지보수성이 증가
3. 예시
   • 라떼 레시피와 아메리카노, 우유 레시피라는 구체적인 내용이 들어있는 하위 클래스가 컨베이어 벨트를 통해 전달되고, 상위 클래스인 바리스타 공장에서 이 레시피를 토대로 생산만 한다.

abstract class Coffee{
    public abstract int getPrice();

    @Override
    public String toString() {
        return "Hi this coffee is "+this.getPrice();
    }
}
class CoffeeFactory{
    public static Coffee getCoffee(String type, int price){
        if("Latte".equalsIgnoreCase(type)) return new Latte(price);	// Enum을 사용하면 if문을 사용하지 않고 매핑 가능하다.
        else if...
    }
}
class Latte extends Coffee{
    private int price;
    public Latte(int price){this.price = price;}

    @Override
    public int getPrice() {
        return this.price;
    }
}
...

Coffee latte = CoffeeFactory.getCoffee("Latte", 4000);
System.out.println("Factory latte: "+ latte); 
// Factory latte: Hi this coffee is 4000

종류가 여러 가지인 경우 및 종류가 계속 추가될 가능성이 있는 경우에 사용하면 유지보수도 편리하고 이해하기 편한 코드가 될 것이다.

 

전략 패턴

1. 특징
   1. 객체의 행위를 바꾸고 싶은 경우 '직접' 수정하지 않고 전략이라고 부르는 '캡슐화한 알고리즘'을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
2. 예시
   1. 물건을 살 때 네이버페이, 카카오페이 등 다양한 방법으로 결제하지만 어떤 방법으로 결제하느냐에 따라 결제 알고리즘이 다를 수 있고 결제 방식의 '전략'만 바꿔 구현

interface PaymentStrategy{
    public void pay(int amount);
}

class NaverPayStrategy implements PaymentStrategy{
    private String name;
    ...

    public NaverPayStrategy(String name, ...) {
        this.name = name;
        ...
    }

    @Override
    public void pay(int amount) {
        System.out.println(amount+" paid using NaverPay");
    }
}
class KakaoPayStrategy implements PaymentStrategy{
    private String name;
    ...

    public KakaoPayStrategy(String name, ...) {
        this.name = name;
        ...
    }

    @Override
    public void pay(int amount) {
        System.out.println(amount+" paid using KakaoPay");
    }
}

// main
cart.pay(new NaverPayStrategy("naver@", ...));
cart.pay(new KakaoPayStrategy("kakao@", ...));

cart.pay부분에서 '전략'을 매개변수로 넣어서 로직을 수행하도록 할 수 있다.

팩토리 패턴과 유사하게 전략 패턴은 어떤 처리 혹은 비즈니스 로직이 종류에 따라 다르다면 사용하는 것이 좋다.

'지불하다'라는 공통적인 기능이 어떤 이름의 방식을 선택하느냐에 따라 다를 때 전략 패턴을 통해 구현하면 유지보수나 확장(다른 지불방식 도입)에 유연하게 대처할 수 있을 것 같다.

 

옵저버 패턴

• 주체가 어떤 객체(subject)의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴
• 주로 이벤트 기반 시스템에 사용하며 MVC패턴에도 사용된다.
  • View가 Observer이고 Controller가 EnventListener, Model이 Observer에게 변경사항을 알려주는 것
  • 모델(주체)에서 변경사항이 생겨 update() 메서드로 옵저버인 뷰에 알려주고 이를 기반으로 컨트롤러가 작동
• 프록시 객체를 통해 옵저버 패턴을 구현할 수 있다.
  • 프록시 객체는 어떠한 대상의 기본적인 동작의 작업을 가로챌 수 있는 객체
  • 프록시 객체를 앞에 두어 접근, 함수 호출 등의 동작을 가로채고 변경과 같은 일이 벌어졌을 때 알려주는 방식
  • ex: Vue.js ref나 reactive로 정의하면 해당 값이 변경되었을 때 자동으로 DOM에 있는 값이 변경되는 것을 프록시 객체와 옵저버 패턴으로 구현한 것.

옵저버가 알림을 받는 녀석들인 것! (주체가 객체(옵저버)에게 알려주다)

프록시 패턴과 프록시 서버

프록시 객체는 사실 프록시 패턴이 녹아들어 있는 객체이다.

• 프록시 패턴은 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴

출처 : https://blog.naver.com/jhc9639/222704234059

• 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용
• 프록시 객체와 프록시 서버에 사용됨

 

• 프록시 서버
  • 프록시 서버는 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램을 가리킴
  • 대표적인 예시가 nginx이며 nginx와 reverse proxy에 관한 자세한 설명은 이 글을 참조! 꼭 읽어야 함 매우 중요!

 

이터레이터 패턴

• 이터레이터(iterator)를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴
• 순회할 수 있는 여러 가지 자료형의 구조와는 상관없이 이터레이터라는 하나의 인터페이스로 순회 가능
• itrerable 한 객체의 순회를 같은 방식으로 할 수 있다.

노출 모듈 패턴

• 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴
  • 즉시 실행 함수 - 함수를 정의하자마자 바로 호출하는 함수. 초기화 코드, 라이브러리 내 전역 변수의 충돌 방지 등에 사용

MVC 패턴

출처:XESCHOOL

• 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴
• 애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있다
• 재사용성과 확장성이 용이하다
• 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있다

모델

• 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻함
• Data, 정보들의 가공을 책임지는 컴포넌트
• 예를 들어 사각형 모양의 박스 안에 글자가 들어있다면, 네모 박스의 화면 위치정보, 글자 내용, 글자 위치, 글자의 포맷 정보 등을 가지고 있어야 한다는 것

규칙

• 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
• 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
  • 모델의 속성 중 텍스트 정보가 변경된다면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보냈을 때 이를 수신할 수 있는 처리 방법을 구현해야 한다.

뷰

• input 텍스트, 박스, 등과 같은 사용자 인터페이스 요소를 말한다.
• 데이터 및 객체의 입력, 보여주는 출력을 담당
• 데이터를 기반으로 사용자들이 볼 수 있는 화면

규칙

• 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
  • 모델이 가지고 있는 정보를 전달받게 될 텐데, 그 정보를 유지하기 위해서 임의의 뷰 내부에 저장하면 안 됨
  • 화면에 표시하기만 하고 그 화면을 그릴 때 필요한 정보들은 저장하지 않아야 함
• 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.
  • 뷰는 데이터를 받으면 화면에 표시해주는 역할만 가진다
• 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야만 한다.
  • 모델과 같이 변경이 일어났을 때 이른 누군가에게 변경을 알려줘야 하는 방법을 구현

컨트롤러

• 데이터와 사용자 인터페이스 요소들을 잇는 다리 역할
• 사용자가 데이터를 클릭하고, 수정하는 것에 대한 이벤트들을 처리하는 부분

규칙

• 모델이나 뷰에 대해서 알고 있어야 한다.
  • 모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고 수신하는 방법만 가지고 있어 컨트롤러가 중재하기 위해 모델이나 뷰에 대해 알고 있어야 한다.
• 모델이나 뷰의 변경을 모니터링해야 한다.
  • 모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지
  • 메인 로직은 컨트롤러가 담당

MVP 패턴

• MVC 패턴에서 파생되어 컨트롤러가 프레젠터(presenter)로 교체된 패턴
• 뷰와 모델의 변경 알림 관계를 끊어내고 오직 프레젠터하고만 변경, 알림을 통해 갱신한다
• 프레젠터하고 일대일 관계이기 때문에 MVC패턴보다 더 강한 결합을 지닌다

• VIEW에서 어떤 변경이 발생
• PRESENTER로 해당 이벤트 처리 메서드 호출
• MODEL에서 데이터 처리 및 비즈니스 로직 처리 후 변경된 데이터를 PRESENTER로 전달
• PRESENTER는 VIEW로 데이터를 전달하여 VIEW에서 화면 갱신

MVVM 패턴

• MVC에서 컨트롤러가 뷰 모델(view model)로 바뀐 패턴
• 뷰 모델은 뷰를 더 추상화한 계층
• MVC패턴과 다르게 커맨드와 데이터 바인딩을 가짐
  • 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원
  • UI를 별도의 코드 수정 없이 재사용할 수 있고 단위 테스팅하기 쉽다

출처: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel

커맨드: 여러 가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법

데이터 바인딩: 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법으로, 뷰 모델을 변경하면 뷰가 변경된다.

• 패턴의 예: Vue.js
  • 반응형 웹이 특징인 프레임워크 - watch와 computed 등으로 쉽게 반응형적인 값 구축
  • 함수를 사용하지 않고 값 대입만으로도 변수가 변경되며 양방향 바인딩, html을 토대로 컴포넌트를 구축
  • 재사용 가능한 컴포넌트 기반으로 UI 구축

 

간단하게 자주 쓰이는 디자인 패턴을 정리한 것 같다.

특히 우리가 프레임워크를 많이 사용하는데 어떻게 적용되는지 알 수 있는 것이 큰 것 같다.

우리가 사용하는 프레임워크가 어떤 패턴으로 구축되었는지 알면 이용하는 입장에서 그 의도를 알고 더 잘 사용할 수 있지 않을까?