Design Pattern을 창시한 GoF의 한명이자, Framework 설계의 대가 Ralph Johnson. 소프트웨어 설계에 관심있는 분이라면, 한번쯤은 들어보셨을 겁니다.

Framework Design Guideline 번역을 위해, Framework 관련 Paper들을 계속해서 읽고 있습니다. 그러면 꼭 만나는 분이 Ralph Johnson입니다.

그는 Martin Fowler의 직,간접적인 스승이며, 그가 이 분야에 미치는 영향은 실로 대단합니다.

아래와 같이 Framework에 관련된 논문을 4개 쓰셨는데요.

• Designing Reusable Classes
• Reusing Object-Oriented Design
• Documenting Frameworks Using Patterns
• Patterns For Framework Evolution.

그 중 가장 마지막 자료인 Evolving Frameworks 논문을 다 읽고, 이 POST를 통해 여러분과 공유하는 시간을 가지고자 합니다.

이 논문은 9가지 패턴으로 구성되어 있는, 위 그림과 같이 시간이 지나면서 언제 해당 패턴을 적용해야 하는지, 연관된 패턴은 무엇인지를 설명하고 있습니다.

Three Example

특정 도메인을 위한 Framework를 개발할려고 할때, 여러분이 참고로 할만한 Framework Reference도 없고, 설계 경험도 없다면 어떻게 해야 할까요?

그럼 세개의 Application을 이용하여 Framework를 설계해야 합니다.  Application 하나로 먼저 Framework을 구축하고, 두번째 Application을 적용하면서 Framework을 다듬고, 이런 식으로 세번을 하면 어느정도 안정적인 Framework이 나올수 있습니다.

Whitebox Framework

Framework를 사용하는 두번째 Application을 만들때, 어떻게 해야 할까요? 첫번째 Application을 작성하기 위해 사용했던 Framework를 상속(Inheritance)을 이용해 확장해야 할가요? 다형성을 기반으로한 Composition(조합)을 써야 할까요? 물론 저의 생각은 예전 Posting에서 언급한 것과 같이 두가지를 적절히 조합해서 사용해야 된다는 것입니다.

모든 Pattern들이 그렇듯이 상속을 이용하여 계약 기반의 일원화된 Interface를 확립함으로써, 클라이언트는 필요에 따라 적절한  Concrete Class를 조합하여 이용함으로써, 확장성및 유연성을 가져올수 있습니다.

위 문장이 이해가 가지 않으시는 분은 제가 예전 블로그에 포스트한 “잘못 알려진 디자인 패턴의 두번째 원칙”을 읽어 보시면 좀더 명확해 지실 겁니다.  시간이 될때 추후 이 블로그로 옮겨 와야 겠네요 ^^

다시 돌아와 단지 재사용의 관점에서 상속을 이용하면 변하는 것과 변하지 않는 것을 쉽게 구분할수 있습니다. 여기서 변하는 부분들을 상속관계로 Subclass를 만들어 사용합니다.

상속을 통해 전체 Framework의 흐름을 일관성 있게 제어할 수 있습니다. (추후 변하지 않는 부분들은 추후 Blackbox Framework로 구성합니다.)

Component Library

Whitebox Framework 기반으로 두번째 Application을 순차적으로 개발할때, 어떻게 유사한 Object를 Framework에서 각각 Instacne화 하는 것을 피할수 있을까요?

정답은 공통화된 내용이나 흐름을 조절하는 추상 Class(대표적인 경우 Template Method Pattern) 들은  Framework에 두고, 실제 Concrete Class들을 Application내에 존재하게 하면 됩니다. 그리고 다양한 Application으로 부터 생성된 Concrete Class를 취합하여 Component Library를 구성함으로서, 재사용성을 높이는 것입니다.

Framework와 Library를 구분하는 방법은 여러가지가 있지만, 가장 큰 차이는 흐름을 제어하는 Flow Control의 차이입니다. Framework는 Flow Control을 가지고 있어 내부적으로 어느정도 흐름을 제어할 수 있게 해주기 때문에, 개발자가 좀더 쉽게 사용할 수 있는 Semi-Application이라고 불리웁니다. 이 맥락으로 볼때 Ralph Johnson 역시 Framework를 통해서 전체적인 흐름을 제어하고, Component Library를 통해서 재사용을 확보함으로써, 확장성(유연성), 재사용성을 확보하는 일거양득를 노렸다고 볼수가 있습니다.

Hot Spots

Component Library에 Component를 계속해서 추가할때, 계속해서 작성되어지는 유사한 코드(Hot Spot)가 발견된다면 이걸 어떻게 해결해야 할까요?

변하는 것과 변하지 않는 코드를 구분해서 변하는 코드들을 객체 형태로 캡슐화해야 합니다. 그리고 캡슐화한 변하는 부분을 한곳으로 취합함으로써, 좀더 쉽게 관리를 할수 있습니다.

이 논문에서는 변하는 부분들을 아래와 같은 디자인 패턴들을 적용하여 캡슐화하라고 권하고 있습니다.

Pluaggable Object

Component Library에 Component를 추가할때, 작성하는 SubClass(Concrete Class)들 대부분이 아주 조금씩 다르게 작성된다면 어떻게 해야 할까요?

Refactoring에서나 Composite Message Pattern에서 언급하듯이Parameter Object로 만들어야 합니다. 저같은 경우는 메세지의 변화가 전체 객체의 일부 Filed을 뽑아서 사용하는 경우라면 Enumeration(예를 들어 사람인 경우 사람.거주정보 , 사람.회사원정보)을 이용하고, 다양한 메세지 포멧을 지원하는 것이라면 파라메터들을 Protocol화여 종종 사용합니다.

Fine-Grained Object

Component Library를 좀더 재사용 가능하게  Refactoring하고 싶다면,  어떻게 해야 할까요?  Ralph Johnson 현재 BPMS와 같이 도메인 전문가가 자동으로 Composition해서 하나의 Application을 생성하는데 목적이 있습니다.  그래서 될수록 객체를 잘게 쪼개는 것을 권하고 있습니다. 여러개의 Behavior를 캡슐화한 클래스를 Component Library에서 찾은 후 각각의 Behavior를 캡슐화할 수 있는 개별적인 여러개의 클래스를 생성해야 합니다. 그후 여러개의 클래스를 조합해서 요구하는 Behavior를 생성할 수 있게 만들어야 합니다.

BlackBox Framework

Whitebox(Inheritance – 상속)로 Framework를 계층화하여 일원화된 흐름을 제공한 다음, Blackbox(Composition-조합)을 통해 런타임시에 Application을 구성할수 있는 유연성과 코드의 중복을 감소하자는 것이 Blackbox의 핵심입니다. Whitebox를 통해 만들어진 상속 관계로 구성된 여러 클래스에서 공적으로 사용되는 코드(변하지 않는 부분)들을 추출하여 이 부분을 Component(Blackbox)화 하여 사용하십시오.

그외의 Topic들 (Visual Builder와 Language Tools)은 AOM(Adaptive Object Model)을 통해 유연한 Application들 만드는 것(마치 BPMS로 하나의 Application을 구축하는 것)을 다루고 있으므로 생략하도록 하겠습니다.

이것으로 간단히 논문 내용의 정리를 마치고, 좀더 자세한 내용을 원하시는 분은 Evolving Frameworks 논문과 제가 올린 Mindmap을 보시길 권해드립니다.  클릭하시면 풀이미지를 얻으실 수 있습니다.

혹시 Freemind로 구성된 실제 Mindmap 파일이 필요하신 분은 개인적으로 연락주세요 🙂

Evolving Framework MindMap 파일 FreeMind 의 MindMap 파일 원본을 요청하신분이 많으셔서 올려드립니다.