음악재생) MVC

이하연·2021년 8월 15일
0

Boostcourse

목록 보기
7/20

1. 디자인 패턴

  • 소프트웨어를 설계할 때 특정 상황에서 자주 사용하는 패턴을 정형화한 것이며, 좋은 소프트웨어 설계를 위한 개발자들의 경험적 산물

  • 장점

    • 의사소통에 도움을 준다.
    • 소프트웨어 개발 비용을 줄일 수 있습니다.
    • 코드 수준을 한단계 높여주고 적은 수의 클래스로 원하는 목적을 달성할 수 있는 환경이 제공된다.
    • 패턴 이름만으로도 개발자들은 그 소프트웨어 구조를 알 수 있습니다. 이를 통해 SW개발에서 사용한 설계나 구조를 쉽게 이해할 수 있고 새로운 소프트웨어로 빠르게 적용가능하다. → SW 재사용 쉽게 해줌

2. 디자인 패턴 분류

새로운 소프트웨어를 개발시 어떤 클래스를 만들고 어느 시점에 객체를 생성하고 소멸시킬지, 데이터를 어떻게 받아서 처리할지, 구조 설계를 어떻게 할지 정해야 하는데, 디자인 패턴이 코드 작성시 반복되는 특정 상황에서 설계를 용이하게 하며, 코드의 재사용이 용이하도록 패턴을 정리해 놓은 것이다.

목적

패턴이 무엇을 하는지 정의하는 것으로 "생성","구조","행위" 중 한가지 목적을 갖습니다.

  1. 생성
    • 객체의 생성 과정에 관여하는 패턴
  2. 구조
    • 클래스나 객체의 구성을 통해 더 큰 구조로 만들 수 있게 해주는 것과 관련된 패턴
  3. 행위
    • 패턴을 주로 클래스에 적용하는지 아니면 객체에 적용하는지에 따라 구분되는 패턴

범위

패턴을 클래스에 적용하는지 아니면 객체에 적용하는지에 따라 구분되는 패턴

  1. 클래스 패턴

    • 클래스들과 하위 클래스 간의 관계를 다루는 패턴
    • 컴파일 시 관계가 결정
  2. 객체 패턴

    • 객체 간의 관계를 다루며 보통 구성을 통해 정의

    • 일반적으로 실행시간에 관계가 생성

      → 동적이면서 유연

종류

목적 / 범위

  1. 싱글턴 패턴
    • 생성 / 객체
    • 객체의 생성에 관련된 패턴
    • 특정 클래스의 인스턴스가 오직 하나임을 보장하고 이 인스턴스에 접근할 방법을 제공
    • 제가 찾아본 싱글톤이 쓰이는 곳은 앱 전체에 하나 존재하는 UIApplication 객체, 파일 접근을 돕는 FileManager, 알림 센터 NotificationCenter 객체, 데이터 지속성이 필요한 정보(앱 내 설정) UserDefaults 객체, 네트워크 통신을 위한 URLSession 객체 에서 찾아볼 수 있었습니다.
  2. 퍼사드 패턴
    • 구조 / 객체
    • 시스템의 복잡성을 줄이기 위해 서브 시스템을 구조화하고 서브 시스템으로의 접근을 하나의 퍼사드 객체로 제공하는 패턴
    • 개발자가 사용해야 하는 서브 시스템의 가장 앞쪽에 위치하면서 하위 시스템에 있는 객체들을 사용할 수 있도록 하는 역할을 한다.
  3. 옵저버 패턴
    • 행위 / 객체
    • 객체의 상태 변화를 관찰하는 관찰자들
    • 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 패턴
  4. 스트래티지 패턴
    • 행위 / 객체
    • 알고리즘을 담당하는 각각의 클래스를 만들어 책임을 분산하기 위한 목적으로 만든 행위 패턴
  5. 팩토리 패턴
    • 생성 / 클래스
    • 객체를 생성하기 위한 인터페이스를 정의하지만 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 하위 클래스에서 이루어지도록 인스턴스 생성의 책임을 떠넘기는 패턴입니다.
  6. 어댑터 패턴
    • 구조 / 클래스,객체
    • 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴
    • 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 동작하도록 해줍니다.

질문

Q. 디자인 패턴이 모든 상황에서 좋은 건 아닙니다. 예를 들어 싱글톤 패턴이 적절치 못한 상황에서는 독이 될 수 있는데 어떤 경우에는 오히려 싱글톤 패턴이 사용하면 안좋을까요?

A.


1. MVC

MVC 디자인 패턴은 애플리케이션의 객체를 모델, 뷰, 컨트롤러 세가지 역할 중 하나의 역할로 할당합니다.

이 패턴은 애플리케이션 내에서 객체가 수행하는 역할 뿐만 아니라 객체가 서로 소통하는 방식을 정의합니다.

1) 모델 객체 Model

  • 애플리케이션과 관련된 데이터를 캡슐화

  • 해당 데이터를 조작하고 처리하는 로직과 계산을 정의

  • 하나의 모델 객체는 다른 모델 객체와 일대일 , 일대다 대응 관계를 맺을 수 있음

  • 단, 데이터를 사용자에게 제공하거나 사용자가 이를 편집할 수 있는 뷰 객체에 명시적으로 연결되선 안됨

    • 즉, 사용자 인터페이스나 표시 문제와 관련 있어서는 안됨
  • 스위프트 언어를 사용하는 경우에는 특별한 경우가 아니라면 NSObject를 상속받지 않습니다.

  • 값 타입의 모델이 필요한 경우 클래스 대신에 구조체를 활용

  • 서브 클래스 구현시 클래스 디자인에서 다음 사항을 고려

     인스턴스 변수

    애플리케이션 내에 캡슐화된 데이터를 유지하기 위한 인스턴스 변수를 선언합니다. 인스턴스 변수는 객체, 스칼라 값, 또는 NSRange와 같은 구조체(structure)일 수 있습니다. 비객체형(nonobject types)대신 객체형을 사용하는 데에는 장단점이 있으므로, 객체 상호 관계(object mutuality)를 고려해야 합니다.

     접근자 메서드(Accessor methods)와 프로퍼티

    접근자 메서드는 일반적으로 인스턴스 변숫값을 획득 및 설정하며, 흔히 획득자 및 설정자 메서드(getter and setter methods)라고도 알려져 있습니다. 스위프트의 언어를 사용하는 경우, 인스턴스 변수를 private 또는 fileprivate 등으로 접근을 제한한 경우, 인스턴스 외부에서(fileprivate의 경우는 다른 소스파일에서) 접근하려면 접근자 메서드가 필요합니다.

     키-값(Key-value) 코딩

    키-값 코딩은 클라이언트가 프로퍼티 이름을 키로 사용하여 객체의 프로퍼티에 접근할 수 있게 하는 메커니즘입니다. Core Data에서 사용하고 있으며 Cocoa의 다른 곳에서도 사용하고 있습니다. 접근자 메서드의 이름 지정 (또한, 암시적으로는 선언된 프로퍼티의 이름 지정)이 이 메커니즘의 요소가 됩니다.

     초기화  할당 해제 (Initialization and deallocation)

    대부분 모델 클래스는 인스턴스 변수를 적절한 초깃값으로 설정하는 이니셜라이저 메서드를 구현합니다. 여기서 초기화는 이니셜라이저 메서드의 표준 형식을 따라야 하며, deinit 메서드에서 객체 값을 가지는 모든 인스턴스 변수를 해제해야 합니다.

     객체 인코딩

    모델 클래스의 객체를 보관하려는 경우, 해당 객체의 인스턴스 변수를 인코딩 및 디코딩할 수 있어야 합니다.

     객체 복제

    클라이언트가 모델 객체를 복제할 것으로 예상하는 경우, 클래스에서 객체 복제를 구현해야 합니다.

2) 뷰 객체 View

  • 애플리케이션 내에서 사용자가 볼 수 있는 객체
  • 자신이 보이는 방법을 알고 있고 사용자 동작에 응답할 수 있다.
  • 주된 목적은 애플리케이션의 모델 객체의 데이터를 보여주고 해당 데이터를 편집할 수 있도록 하는 것

3) 컨트롤러 객체 Controller

  • 하나 이상의 애플리케이션 뷰 객체와 하나 이상의 모델 객체 사이의 코디네이터 또는 중개자 역할
  • 화면에 표시하는 뷰를 관리하며, 해당 뷰에 대한 참조(reference)를 유지하고, 뷰 컨트롤러는 이 뷰의 프레젠테이션(presentation) 및 후속 뷰로의 전환(transition)을 관리
  • 이와 관련된 모든 프레젠테이션 동작 뷰 컨트롤러 객체에 의해 관리되고 구현
  • 뷰 컨트롤러는 여러 가지 프레임워크 객체에 대한 델리게이트 혹은 데이터 소스 객체인 경우가 많습니다.
  • 애플리케이션의 설정 및 조정 작업을 수행할 수도 있으며, 다른 객체들의 생애주기(life cycle)를 관리
  • 형태가 없고 보이지 않는 곳에서 뷰를 조정
    • 역할은 보이지 않는 곳에서 우리 뷰를 조정하고 모델 클래스와 같이 소통하면서 데이터를 주고받고 업데이트하는 역할을 수행합니다.
    • 중간에서 모델과 뷰 사이에서 중재하는 역할을 합니다.
  • iOS 환경의 Cocoa Touch 프레임워크는 코디네이팅 컨트롤러, 뷰 컨트롤러의 두 가지 기본 컨트롤러 유형을 제공합니다.
  • UIViewController 서브클래스의 인스턴스

코디네이팅 컨트롤러

코디네이팅 컨트롤러는 애플리케이션 전체 혹은 일부 기능을 감독하고 관리 합니다. 애플리케이션별로 다른 로직이 각 애플리케이션에 주입(injected)되는 장소라고 할 수 있으며, 그 기능은 다음과 같습니다.

◦ 델리게이션(delegation) 메시지에 응답하고 알림(notifications)을 관리.

◦ 사용자가 버튼과 같은 컨트롤을 탭 하거나 클릭함에 따라 전송되는 동작 메시지(action message)에 응답.

◦ 객체 간의 연결을 확립하거나 기타 설정 작업을 수행. (예: 애플리케이션을 시작하는 경우)

◦ 소유한(owned) 객체의 생명 주기 관리.

  • iOS 애플리케이션에서는 뷰 컨트롤러가 코디네이팅 컨트롤러의 역할을 겸하는 경우가 많습니다.

  • MVC 모델 외에도 MVP(Model-View-Presenter), MVVM(Model-View-ViewModel)등 다양한 디자인 패턴에 대해서도 알아봅시다.
  • UIKit은 UITableViewController와 같은, UIViewController의 여러 특수 목적 서브클래스를 제공

0개의 댓글