Evolving Framework

1. Evolving Framework Frameworks Day– 패턴 언어를 이용한 객체지향 프레임워크 구축 김용현 drvoss@gmail.com Microsoft MVP Devpia Architecture Sysop ALYac Dev team, ESTsoft Architecture&Design Eva

2. 프레임워크 만들기 • 애플리케이션 개발 전 • “막연하게 어렵다” • 애플리케이션 개발 중 • “쉽게 만들 수 있을 것 같다!” • 애플리케이션 개발 완료 후 • “발전 시킬 방향이 모호 하다” • “어떻게 처리 해야 될지 모르겠다” • “이전 애플리케이션 때 썼던 라이브러리 처럼다음번 라이브러리에 참고 하도록 백업해 놓겠다” Evolving Framework

3. 생산성 향상 Evolving Framework

4. 객체지향과 재사용 • 콤포넌트의 재사용 • 검증된 코드를 사용 • 소프트웨어 품질을 높임 • 개발 비용 감소 • 유지 보수 비용 감소 • 신뢰성 있는 객체 • 생산성 향상 • 아키텍처의 재사용 • 판단, 직관적통찰 • 의지, 의도, 컨디션 Evolving Framework

5. 프레임워크의 정의 “프레임워크란 추상클래스(abstract class)들의 집합과 상호 협조하는 클래스들의 인스턴스 동작방법으로 이루어진 재사용이 가능한 디자인 이다.” - 랄프존슨(Ralph Johnson) Evolving Framework

6. 프레임워크란, • 애플리케이션, 서브시스템의 재사용성 디자인 • 추상클래스 셋과 객체간 협력 방법으로 구성 • 애플리케이션을 만들기 위해 확장 가능 • 객체로 문제를 분석하고 해결해주는 프리즘 • 객체의 모음 혹은 클래스 군일 뿐만 아니라 인스턴스들이런타임시에상호 협력하는 관계 포함 Evolving Framework

7. 프레임워크의 특징 • 쉽게 확장이 가능하다 • Simple Design Pattern • Complex Pattern • Inversion Of Control Evolving Framework

8. 얻을 수 있는 이득 • 코드를 단일화와 단순화 • 애플리케이션 릴리즈 일정의 단축 • 애플리케이션의 안정성 향상 • 표준 양식이 정해짐 • 원활한 커뮤니케이션 가능 • 코딩방향성 및 수정 방향성 • 유지보수의 원활함 Evolving Framework

9. Agenda • 프레임워크의 정의 • 프레임워크를 사용하는 방법 • 프레임워크를 만드는 방법 • 프레임워크 발전의 9단계 • 레퍼런스 Evolving Framework

10. 프레임워크 사용 방법 • 프레임워크에 포함되어 있지 않은 기능이나 도메인에 특화된 기능을 서브클래싱을 통하여 구현 • 사용할 오브젝트들에 대한 내부 환경을 설정 • 오브젝트끼리의 관계 파악 • 동작이 보증된 예제를 수정 • 스크립트 수정 Evolving Framework

11. 프레임워크를 개발하는 법 • 애플리케이션을 개발하면서 리펙토링을 통하여 공통코드를 얻고 관리 • 계속적으로 다른 애플리케이션을 개발하면서도 같은 작업 반복 • 공통코드를 리펙토링하여 공통영역에 관리함 • 새로 애플리케이션을 작성할 때 더 이상 리펙토링할 여지가 없다면 프레임워크가 완성된 것 Evolving Framework

12. 프레임워크를 디자인 하는 방법 Evolving Framework

13. 하향식 프레임워크 디자인 • 도메인의 문제를 분석 • 알려진 추상화 포인트나 분석을 통한 추상화 포인트를 파악 • 최소 4-5개의 애플리케이션을 수집 • 애플리케이션으로 부터 추상화 디자인 • 프레임워크 테스트 • 몇 개의 애플리케이션을 만들어 테스트 Evolving Framework

14. 하향식 프레임워크 디자인 • 애플리케이션에서 반복되거나 비슷한 부분이 있다는 것을 눈치 챔 • 객체지향언어로 구현되는 다음 애플리케이션이 있다면 프레임워크 디자인을 할 준비 • 재사용 가능한 부분과 가능하지 않는 부분을 나눔 • 새로운 다음번개발때 재사용 가능한 부분을 적용 • 재사용 하는 부분이 적을 경우 프레임워크 디자인 수정 Evolving Framework

15. 하향식 설계 vs상향식 설계 • “People Think Concretely, not Abstractly” • R = I + J = AX + AY = A(X + Y) • 코딩을 하면서 추상화 포인트를 찾아내는것이 일반적 Evolving Framework

16. 객체지향의 5원칙 의존 관계 역전 원칙 The Dependency Inversion Principle 인터페이스 분리 원칙 The Interface Segregation Principle 리스코프 치환 원칙 The Liskov Substitution Principle 단일 책임 원칙 The Single Responsibility Principle 개방 폐쇄 원칙 The Open-Closed Principle Evolving Framework

17. 추상 클래스 유도 • 구현 클래스를 일반화 하면서 추상화 포인트를 발견해 감 • 두개의 클래스를 비교해 가면서 유도 • 비슷한 기능의 각 메소드 이름을 같게 변경 • 인자의 타입과 순서등을재정열 • 분할과 병합 리팩토링 수행 • 만일, 인터페이스 이름이 같고 구현이 다르다면 그곳이 추상화 포인트! Absract클래스 생성! • 만일, 인터페이스 이름이 같고 구현도 같다면 수퍼 클래스로 메소드 이동 Evolving Framework

18. 프레임워크의 단점 Evolving Framework

19. 프레임워크 만들기 전 명심할 점 Evolving Framework

20. 프레임워크를 발전시키는 9개의 패턴 Evolving Framework

21. 각 패턴의 상관 관계와 발전 관계 Evolving Framework

22. Three Examples • 프레임워크를 개발하고 할 때 적용 • 프레임워크 디자인을 위해 어떤 것부터 시작해야 할 것인가 Evolving Framework

23. Three Examples • 많은 예제를 만들어 볼 수록 좀더 재사용가능하고 일반적인 프레임워크가 됨 • 프레임워크 작업으로 인하여 생기는 릴리즈 일정 지연 고래 해야 함 • 일반화를 위한 3개 이상의 애플리케이션 작성이 요구됨 • 한 개의 팀에서 애플리케이션과 프레임워크를 동시에 작성 vs애플리케이션과 프레임워크를 각각의 팀에서 작성 Evolving Framework

24. White-box Framework • 두번째 애플리케이션을 개발 할 때 적용 • 프레임워크 구조를 상속에 기반할 것인가 다형성 조합에 기반할 것인가 Evolving Framework

25. White-box Framework • 상속은 콤포넌트 끼리 강결합을 이루게 함 • 새로운 클래스 작성은 프로그래밍이 수반 • 조합은 콤포넌트 재사용을 아주 높여 주지만 코드를 봤을때 한번에 이해하기 어렵게 함 • 조합은 런타임시에 기능이 변경되기 수월함 • 상속은 컴파일타임에 기능이 고정되어 버림 Evolving Framework

26. White-box Framework • 상속을 이용하여 프레임워크를 구성하라 • 애플리케이션을 거듭할 때 마다 공통적인 부분을 프레임워크에 놓고 서브클래스, 메소드오버라이드를 통해 기능 추가 • 기능이 같은 메소드를 발견하면 프레임워크에 새로운 메소드 생성 • 상속은 기능을 객체지향프로그래밍에서 기능을 확장 시키는 일반적인 방법 • 추상클래스는 메소드의 책임 있는 확장성을 부여 Evolving Framework

27. Component Library • White-box 프레임워크를 이용해서 예제를 구현해봤거나 두번째애플리케이션때 적용 • 프레임워크에 기능이 중복되어 생성되는 인스턴스 제거 Evolving Framework

28. Component Library • 작은 라이브러리로 시작해서 오브젝트를 하나씩 추가 하는 형태로 발전시킴 • 추가된 오브젝트가 추후 도메인에 특화된 오브젝트일 경우 프레임워크에서 제외시킴 • 프레임워크에 추가된 객체지만 오랫동안 재사용되지 않으면 제외시킴 • 콤포넌트가 많아지면 추후 패턴을 적용하여 작은 서브콤포넌트들로리펙토링 시킴 Evolving Framework

29. Hot Spots • 콤포넌트 라이브러리에 콤포넌트를 추가 할 때 적용 • 같은 코드가 중복되어 프레임워크에 반영되지 않도록 함 Evolving Framework

30. Hot Spots • 변화성이 있는 코드와 그렇지 않은 코드 분리 • 코딩하는코드량을 줄여줌 • 중복을 제거함 • 클래스와 메소드를 다양한 부분으로 분리 • 디자인 패턴 적용 • 알고리즘, 액션, 구현, 변화 통지, 오브젝트간 인터액션, 객체 생성, 구조 생성, 반복 알고리즘, 객체 인터페이스, 객체 행위 Evolving Framework

31. Pluggable Objects • 콤포넌트 라이브러리에 콤포넌트를 추가 할 때 적용 • 서브클래스가 무수히 늘어나는 문제를 방지 Evolving Framework

32. Pluggable Objects • 일부 클래스는 간단한 기능을 위한 상속임 • 상속 받고 있는 메소드가 소멸자만 있는 경우 • 새로운 클래스 증가는 복잡함으로 이어짐 • 서브 클래스를 파라미터를 넘겨 적용시킴 • Constant, Symbol, Class reference, Function Pointer, etc Evolving Framework

33. Fine-grained Objects • 콤포넌트 라이브러리를 좀더 재사용성이 용이하도록 리펙토링 할 때적용 • 얼마나 오브젝트를 작게 구분할 것인가 Evolving Framework

34. Fine-grained Objects • 객체가 커질수록 중복되는 기능과 코드를 가질 수 있는 확률이 높아짐 • 하나의 객체가 도메인문제와 직접적 의미가 없어질 때 가지 분리시킴 • 기존에 큰 객체가 사용되고 있는 자리는 작은 객체로 나누고 조합을 이용하여 기능을 만들어 냄 Evolving Framework

35. Black-box Framework • Hot Spots을 캠슐화하여 Pluggable Object를 개발하고 Fine-grained Object로 분리할 때 적용 • 프레임워크를 적용할 때 상속과 조합중 선택 Evolving Framework

36. Black-box Framework • Hot spots단계에서 Fine-grained Object를 추가하다 보면 점점 Black-box화 되어감 • 프레임워크를 사용할 때 상속을 이용할 것인가 조합을 이용할 것인가 • 강결합은 기능 수정에 많은 고려가 필요 • 상속을 이용하여 프레임워크를 구조화 시키고 조합을 이용하여 애플리케이션에 적용하라 Evolving Framework

37. Visual Builder • Black-box Framework을 이용해서 작성되는 애플리케이션 일정을 당기고자 할 때 • 프레임워크 오브젝트 행위를 만드는 스크립트를 간단하고 빠르게 생성 Evolving Framework

38. Visual Builder • 도메인 전문가는 프레임워크 내부를 이해하기 힘들다 • 개발자에게 MSDN, MFC 구조도등을 제공 • 프레임워크를 한눈에 알아볼 수 있도록 비주얼한 화면을 제공 • 스크립트를 자동적으로 혹은 쉽게 작성할 수 있도록 툴을 제공 • 꼭 필요한 경우에만 서브클래스를 통한 기능 추가가 이루어 질 수 있도록 함 Evolving Framework

39. Language Tools • Visual Builder를 만들고 난 후 • 빌더가 생성하는 복잡한 객체 조합을 조사하고 검증하고 디버깅 할 수 있도록 지원 Evolving Framework

40. Language Tools • 복잡한 객체들과 객체사이의 관계 • 프레임워크와 애플리케이션간의 적절한 사용이 되었는지 점검 • 개발자가 디버깅을 위해 프레임워크를 트레이싱한다면 쉽게 지쳐버림 • 코드 조사와 디버깅을 위한 도구 필요 Evolving Framework

41. Reference • 랄프E. 존슨의 프레임워크 정의 • http://st-www.cs.uiuc.edu/users/johnson/frameworks.html • Evolving Frameworks [Don Roberts, Ralph Johnson] - A Pattern Language for developing object-oriented frameworks • 더글라스슈미츠의Networking Programming • http://www.cs.wustl.edu/~schmidt/C++NPv1.ppt • Designing Reusable Classes – Journal of Object-Oriented Programming Evolving Framework

42. Thank you • 이후 피드백 http://www.devpia.com/Forum/mdmIndex.aspx?forumname=and • Software Architecture와 Design Pattern관련 Q&A • Software Architecture와 Pattern 관련 Study 및Online 토론 Evolving Framework