2 분 소요

이번 포스트에서는 MVC Architecture Pattern에 대해 다룬다.

MVC Architecture

MVC란?

  • MVC (Model - View - Control)는 복합 패턴 ( compound pattern) 으로 여러 디자인 패턴을 결합하여 사용

  • 주요 구성 요소:

    • Model: 애플리케이션의 핵심 데이터 및 로직
    • View: 사용자 인터페이스(UI), 화면에 모델 데이터 표시
    • Controller: 사용자 입력을 해석하고 모델/뷰에 전달

MVC structure

MVC Structure

  1. Model
  • Non-UI Layer
  • 응용 프로그램의 상태와 기능을 캡슐화
  • 애플리케이션 기능을 제공하고 변경 발생시 View에 알림
  • UI에 의존하지 않고 재사용이 가능하며 테스트에 용이
  1. View
  • UI Layer : 사용자에게 보여지는 화면 담당
  • Model의 데이터를 받아 시각적으로 표현하고, 상태 업데이트 요청
  • 사용자 동작을 Controller에 전달하고, Controller가 선택한 View를 반영
  1. Controller
  • 사용자 입력을 받아서 Model을 갱신하거나 View를 선택
  • 앱 동작을 정의
  • 사용자 액션을 통해 Model을 업데이트하고, 적절한 View 선택

흐름 요약:

  1. 사용자가 View와 상호작용
  2. Controller가 입력 처리
  3. Model을 변경
  4. Model이 View에 변경 알림
  5. View가 화면 업데이트

MVC motivation & solution

Motivation

  • 하나의 데이터를 **다양한 View에서 보여줘야 한다. **
  • 하나의 데이터를 다양한 interaciton 방식으로 수정해야한다.
  • 이러한 다양한 View나 Interaction이 핵심 기능에 영향을 주면 안된다.
    • UI 변경이 핵심 로직에 영향을 주면 안됨.

요약

하나의 데이터에 여러 View와 Interaction이 가능해야하며, 이것이 핵심 로직을 건드리지 않도록 해야한다.

Solution : 책임 분리 (Separating responsibilities)

  • Core bussiness logic (model), 화면 표현 (view), 제어 흐름 (controller)

MVC Patterns

1. Observer Pattern : View와 Model의 분리

  • Model의 상태 변경을 다수의 View에 알리기 위한 패턴
  • Model이 상태가 바뀌면 View에 통지 후 자동으로 갱신
  • Model은 View의 구체적인 구현을 몰라도 된다.

2. Composite Pattern : 중첩된 View의 구성

  • 여러 View를 트리 구조로 묶어서 하나처럼 다룰 수 있게 함.
  • 복합 위젯을 하나의 단위 처럼 처리하고
  • 단일 인터페이스로 복합객체와 단일 객체를 동일하게 취급

3. Strategy Patern : View -> Controller 위임

  • View가 사용자 입력 해석을 Controller에 위임하고, Controller 교체가 가능함.
  • 컨트롤러는 전략처럼 다양하게 교체가 가능
    • 입력 방식마다 다르게 부착 가능
  • View는 단지 입력을 전달하고, 해석은 Controller가 전담

+ Factory, Decorator Pattern도 존재

  • Factory Pattern : 객체 생성 로직을 추상화
  • Decorator Pattern : View or Controller에 기능을 덧붙이는 방식

Observer Pattern 만족 하기 위함

Observer Pattern

  • 어떤 객체의 상태 변화가 발생했을 때, 이를 관심 있는 다른 객체들이 자동으로 알리는 상태 패턴
  • 즉, 한 객체의 상태가 바뀌면 그 객체에 의존하는 모든 객체들이 자동으로 통지를 받고 갱신된다는 뜻

  • 1대 다 (One-to-Many) 관계이며 자동 업데이트가 핵심

  • 특징
    • Observer 수는 제한 없이 다수가 가능
    • Model은 View의 내부를 알 필요가 없음. -> loose coupling
    • 동적으로 Observer를 붙였다가 뗏다가 가능함.
  • 예시 ) 신문의 구독 모델 (Publisher & Subscriber Model)

Bouncing Ball Applet (Java)

Model

  • 상태: 공의 위치, 방향, 창 크기
  • 기능: 한 스텝씩 움직이기 (makeOneStep()), Observer 알림 포함
class Model extends Observable {
  void makeOneStep() {
    // 위치 이동, 경계 충돌 처리
    setChanged();
    notifyObservers();
  }
}

View

  • Mdoel을 구독
  • 위치를 기반으로 화면 그리기
class View extends Canvas implements Observer {
  public void update(Observable obs, Object arg) {
    repaint(); // 공 위치 다시 그림
  }
}

Controller

  • UI 이벤트 처리 ( 버튼 클릭과 같음)
  • Model, View를 연결하고, Observer 등록
class Controller extends JApplet {
  model.addObserver(view);
  stepButton.addActionListener(e -> model.makeOneStep());
}

Test (Notes)

  • Litmus Test : UI를 바꿔도 Model이 동작하는가?

가능 : Model이 잘 분리되어있고, MVC 원칙을 지켰다는 증거

  • JUnit : Model은 단독으로 테스트가 가능해야한다.

View 나 Controller 없이 테스트가 가능해야 진짜 Model

  • Model 동작은 빠르게 처리되어야 한다.
    • GUI가 멈춰버림.

참고

Concurrency, Locks

8 분 소요

이번 포스트는 OS의 Concurrency와 Locks에 대해 다룬다.