Design Pattern ) 디자인패턴 개요 2편

디자인 패턴 개요 2편을 쓰게 된 이유는

디자인 패턴에 대한 포스팅을 몇 개 보다가 

정리하고 싶은 내용을 발견했기 때문 ! ㅎ

 

[Design-Pattern-In-Swift] 3. 디자인 패턴을 통해 문제를 해결하는 방법

이 글을 바탕으로 정리한 내용입니다.

디자인패턴 중 생성패턴 먼저 공부하기 위해 찾아보다보니

클래스와 객체를 만드는 과정을캡슐화한다.

이런식으로 많이 얘기를 하더라구요 

 

그래서 클래스, 객체, 캡슐화 이런 개념들을 짚고 넘어가좌 ..

고런 느낌입니다..

객체 지향 프로그램에서 객체란 무엇이고, 적당한 객체의 규모를 정하기 위해서

디자인패턴을 쓴다는데 그런 전체적인 흐름 ? 을 보고 넘어가고 싶었습니다 ! 

 

 

1. 객체 지향 프로그램에서의 '객체'

 

객체는 데이터와 데이터에 연산을 가하는 프로시저를 함께 묶은 단위입니다.

프로시저는 일반적으로 메서드 또는 연산이라고 부릅니다.

 

객체는 사용자로부터 요청 또는 메세지를 받으면 연산을 수행하게 됩니다 !

요청은 객체가 연산을 실행하게 하는 유일한 방법,

연산은 객체 내부 데이터의 상태를 변경하는 유일한 방법이라고 합니다 

 

여기서 요청을 던지는 객체 외부에서는 내부 데이터에

직접 접근을 할 수 없습니다.

즉, 내부의 상황을 모르는 것이죠 !

 

이런 상태를 캡슐화되었다고 표현합니다.

 

-

 

객체지향 프로그래밍은 

객체끼리 협력하여 각자의 역할을 수행하는 식으로 구성됩니다.

그렇기 때문에 객체의 분할이 이루어져야합니다.

 

객체의 분할은 

캡슐화, 크기정하기, 종속성, 유연성, 성능, 진화, 재사용성 등등 

다양한 요인을 고려해서 처리해야합니다.

 

디자인패턴을 통해 객체를 어느정도 분할하고

어떤 관점으로 다뤄야하는지에 대한 방법들을 알아보게 될 것 같습니다 !

 

 

2. 객체의 크기 결정하기 

 

프로그램을 설계할 때, 객체는 반드시 몇개를 사용해야 한다! 처럼 정해진게 없습니다

그러면 적당한 객체의 규모는 어떻게 정할까요?

=> 디자인패턴에서 답을 얻자 !

 

1) 퍼사드 패턴 : 서브 시스템을 어떻게 객체로 표현할 수 있는지 설명 

이를 통해 서브 시스템의 객체 크기를 결정할 수 있음

 

2) 추상 팩토리 패턴 / 빌더 패턴 : 다른 객체를 생성하는 책임만 있는 객체를 만들어내는 법을 설명

 

3) 플라이급 패턴 : 규모는 작지만, 개수가 많은 객체를 다루는 방법을 설명

 

4) 방문자 패턴 , 명령 패턴 : 다른 객체가 요청을 처리할 수 있도록 책임지는 객체를 

만들어내는 법을 설명

 

=> 이런 정형화된 패턴을 통해, 각 객체를 어느정도로 분리하는지 파악할 수 있고,

분리한 객체를 어떻게 다루는지에 대한 방법을 이해할 수 있음 !

 

3. 객체 인터페이스의 명세 

 

protocol PlanPreviewRepositoryInterface {
	func fetchBodyData(idx: Int, onCompleted: @escaping ([Int])) -> Void) -> Int
}

객체가 선언하는 모든 연산은 

연산의 이름 (fetchBodyData),

매개변수로 받아들이는 객체 (idx, onCompletd),

연산의 반환값(Int)을 명세합니다.

이를 연산의 시그니처 라고 부르게 됩니다.

 

SOILD 할때 공부했었는데, 스위프트에서는 인터페이스를

프로토콜을 이용해 구현하고 프로토콜 안에 메서드가 시그니처 개념이 됩니다 !

 

그리고 타입은 인터페이스를 나타낼 때 사용하는 이름을 일컫고 있습니다.

프로토콜 이름을 정할 때, 이름 끝에 -type을 사용해 프로토콜 이름을

정하는 경우를 보신적이 있을겁니다! .요러한 맥락을 담아서 네이밍을 진행하기 때문이라고 해요 !

 

-

 

인터페이스끼리는 상속이 가능하기 때문에,

다른 인터페이스가 포함하는 인터페이스를 슈퍼타입이라고 부르며,

다른 인터페이스를 포함하는 인터페이스를 서브타입이라고 부릅니다 !

 

스위프트에서 프로토콜을 상속하게 되면 

서브타입은 슈퍼타입의 정의된 연산을 물려받게 되죠 !

 

외부에서 객체를 알 수 있는 방법은 인터페이스 밖에 없어야 합니다 !!

인터페이스를 통해서만 처리를 요청할 수 있고,

객체의 인터페이스는 어떻게 구현하는지에 대해서는 직접 알 수 없습니다 ! 

왜냐? 캡슐화 되었기 때문이죠 

 

인터페이스는 객체 지향에서의 가장 기본적인 개념이 되고, 

객체는 인터페이스로 자신을 드러내게 됩니다.

 

이러한 요청과 그 요청을 처리할 객체를 프로그램 실행 중에 ,

즉 런타임에 둘을 연결 짓는 것을 동적 바인딩이라고 합니다.

 

동적바인딩은 프로그램이 기대하는 객체를 동일한 인터페이스(프로토콜)를 갖고 있는 객체로

얼마든지 갈아끼우는게 가능하다는 의미가 됩니다. 

=> 이러한 대체성을 다형성이라고합니다 ! 객체 지향 시스템의 핵심 개념이죠.

다형성을 통해 객체간의 결합도를 없애고, 서로 간의 관련성을 다양화 시켜줍니다.

 

서로 다른 객체는 채택한 프로토콜에 정의한 요청의 구현 방법을 

자유롭게 선택이 가능합니다.

결국, 프로토콜이 시킨건 다 만족한 상태에서 각자 처리하는 방식만 달라지는 거죠 !

 

위에서 언급한 인터페이스를 어떻게 작성할지에 관련된 디자인 패턴은

 

1) 메멘토 패턴 : 객체의 내부 상태를 어떻게 저장하고 캡슐화 해야하는지를 정의, 이를 통해

인터페이스에 들어가야할 것, 안될 것을 구분할 수 있음

 

2) 장식자 패턴/ 프록시 패턴 : 장식되고 중재되는 객체와 동일한 인터페이스를 갖도록

장식자/ 프록시 객체의 인터페이스를 요청하는 방법을 정의

이를 통해, 클래스 간에 유사한 인터페이스를 정의하도록 하거나,

클래스의 인터페이스에 여러가지 제약을 정희합니다.

 

4. 객체 구현 명세하기 

 

객체의 구현은 클래스를 정의하는 과정에서 이루어집니다.

클래스는 객체 내부 데이터와 표현 방법을 명세하고, 수행할 연산도 같이 정의하게 됩니다.

 

객체는 클래스를 인스턴스로 만듦으로써 생성이 됩니다.

즉, 객체는 클래스의 인스턴스라고 할 수 있습니다 !

 

클래스는 객체를 만들어내기 위한 설계도라고 하면 

이를 인스턴스화 해서 만든 

인스턴스는 설계도를 바탕으로 구현된 구체적인 실체 ! 입니다

인스턴스는 메모리에 할당이 됩니다.

 

* 인스턴스화 : 클래스의 인스턴스화 과정은 

객체 내부의 데이터에 대한 공간을 할당하고, 이 데이터들을 연산과 

관련짓는 과정입니다 !

 

- 

 

클래스 상속을 통해, 기존 클래스에 기반을 둔 새로운 클래스를 정의할 수 있습니다.

서브클래스는 부모클래스가 물려준 연산이나 구현을 변경할 수 있습니다.

이러한 과정을 오버라이드라고 부릅니다 !

스위프트에서도 오버라이드라는 키워드로 오버라이딩이 가능하죠 !

 

자식클래스는 부모클래스의 기능을 그대로 사용할수도, 구현을 변경할수도,

자신만의 기능을 정의할 수도 있겠죠 !

 

-

 

추상클래스는 모든 서브클래스 사이에 공통되는 인터페이스를 정의합니다.

추상클래스는 인스턴스를 생성할 수 없습니다 

 

추상클래스가 아닌 클래스는 ? 구체 클래스라고 합니다.

구체클래스는 인스턴스를 생성할 수 있습니다 !

 

추상클래스인 protocol A 는

let a = A() 와 같이 인스턴스 생성이 불가능하고

 

구체클래스인 class A 는 

let a = A() 와 같이 인스턴스 생성이 가능합니다.

 

앞서도 말했듯이 스위프트에서는 인터페이스를 프로토콜로 표현하고

프로토콜은 연산에 대한 정의만 있을 뿐, 

구체적인 연산에 대한 구현은 없기 때문에 

데이터와 연산을 연결짓는 행위 즉, 인스턴스화가 불가능 합니다 !

 

 

5. 객체 지향에서 행동 복합하기

 

객체 지향에서는 행동을 복합할 수 있는 방법에 3가지 있습니다

 

1) 상속 : 서브 클래스에 의해 연산을 구현하는 방법

2) 합성 : 다른 객체를 여러개 붙여서 새로운 기능 혹은 객체를 구성하는 방법

3) 매개변수화 : 타입을 정의할 때 타입이 사용하는 모든 타입을 지정하지 않은 채 정의하는 방법

 

 

-

 

상속 

 

서로 다른 클래스의 객체들이 동일한 타입(프로토콜)을 가지고,

구현은 제각각으로 할 수 있습니다.

특정 객체가 어떤 클래스의 인스턴스라고 말할 때, 

그 객체는 클래스가 정의한 인터페이스를 지원한다는 뜻이 숨겨져 있다.

 

- 클래스 상속 : 객체의 구현을 정의 할때, 이미 정의된 객체의 구현을 바탕으로 한다.

코드와 내부 표현구조를 공유하게 된다. 이미 다 갖춰진 연산과 데이터를 받아서 처리한다.

( 완제품을 받아서 거기에 살만 붙여서 새로운 객체를 빠르게 정의할 때 사용 )

기존 클래스를 그대로 상속해서 사용할 수 있다면, 

새로운 구현에 드는 비용은 적은 편 ! 하지만 그대로 구현을 물려받는다고

재사용이 완벽하게 이루어지지는 않음

 

- 인터페이스 상속 ( 프로토콜 상속 ) : 연산의 정의만 물려받게 되는 형식

이를 통해, 어떤 객체가 다른 객체 대신에 사용될 수 있는 경우를 지정할 수 있게됨

이러한 인터페이스 상속의 장점 ?

사용자가 원하는 인터페이스를 그 객체가 만족하고 있는 한, 사용자들은 그들이 사용하는

특정 객체 타입에 대해 알 필요가 없다.

사용자들은 이 객체들을 구현하는 클래스를 알 필요가 없고, 프로토콜에게만 시키면 된다.

=> 이러한 원칙을 통해 서브 시스템간 종속성이 없어진다 !

따라서, 구현이 아닌 인터페이스에 따라 프로그래밍을 하는 것을 권장하고 있다

 

* 어떤 변수를 구체 클래스의 인스턴스로 선언하는 일을 피하자 : DIP 위반 

대신, 추상 클래스의 인터페이스르 따르는 인스턴스 변수를 정의해야한다 -> 의존성 주입

 

 

- 

 

합성 

 

클래스 상속은 다른 부모 클래스에서 상속받아,

메서드와 데이터를 물려받아 한 클래스의 구현을 정의하는 것

부모클래스의 내부가 서브 클래스에 공개되기 때문에

화이트박스 재사용이라고 부르기도 함

 

객체 합성 : 다른 객체를 여러개 붙여서 새로운 객체를 구성하는 것으로,

합성에 들어가는 객체들의 인터페이스들을 정확히 정의해두고,

해당 인터페이스들을 재사용하는 방식을 통해 정의된다.

 

객체의 내부는 공개되지 않고 인터페이스를 사용하기 때문에 '블랙박스 재사용'

이라고 부르기도 함

 

여기서 클래스의 상속은, 서브클래스가 부모 클래스이 구현에 종속될 수 밖에 없으므로

부모 클래스 구현에 변경이 생기면 서브클래스에도 변경이 있어야 함 !

 

객체 합성을 하게 되면, 각 클래스 간 캡슐화 유지가 가능하고

클래스의 1가지 작업에 집중할 수 있다.

스위프트의 massive viewcontroller를 막을 수 있다.

종속성이 줄어들고 캡슐화를 유지할 수 있기 때문에 객체합성이 클래스 합성보다 

더 나은 방법이라고 할수 있다.

 

but, 합성만으로는 프로젝트를 설계하기 불가능하므로 상속과 객체 합성은 적절히 조합 !

 

-

 

매개변수화 : 타입을 정의할 때 타입이 사용하는 모든 타입을 지정하지 않은 채 정의

 

기능의 재사용에 이용할 수 있는 다른 방법은 매개변수화된 타입을 지정하는 것

스위프트에서는 제너릭이라는 기능을 통해 가능합니다. 

객체를 생성할 때, 타입을 명시하는 것이 아니라 나중에 지정하도록해서 조금 더 유연하게 

객체 설계가 가능합니다. 

 

struct Stack<T> {
	var items = [T]()
    mutating func push(item: T) {
    	items.append(item)
	}
    mutating func pop() -> T {
    	return items.removeLast()
	}
}

var stackOfAny = Stack<어떤 타입이든 가능>()

 

6. 런타임 vs 컴파일 

 

많은 디자인 패턴들은 컴파일 시점과 런타임 구조를 명시적으로 구분하고 있음

왜일까요

 

코드 구조의 경우에는 컴파일 시점에서 확정이 됩니다 : 영속적 개념

교류하는 객체가 어떻게 협력하느냐에 따라 변하는 것은 런타임 시점에 일어납니다 : 유동적 개념 

=> 어떤 개념이 변하고 변하지 않는 다는 것을 명시해서 런타임 구조를 설계해야함 !

 

재사용을 최대화하기 위해서는

새로운 요구 사항과 앞으로 발생할 변경을 예측해 

앞으로의 시스템 설계가 진화할 수 있도록 해야함 

 

결국 변화에 잘 대응하기 위한 소프트웨어를 만들기 위해서는

어떤 변화를 어떻게 수용할지를 고려해야한다는 것입니다 !

 

결론적으로 디자인패턴을 통해 

객체별로 독립적으로 변화에 적응 할수 있는 구조를 만들어 둬서 

특정 변화에 순응할 수 있기 때문에 ㅇ위와 같은 위험도를 줄일 수 있게 됩니다.