Pattern이라는 분야에서 GoF의 Design Patterns가 가지는 의미는 굳이 말을 하지 않아도 될듯 합니다.
몇몇 지식 계층들을 위한 학회에서나 애기되어지고 있는 Pattern들을 일반인들에게 알리는 신호탄 같은 존재이기 때문입니다.
예전 블로그에 올린 글이지만, 패턴을 공부하시거나 접하시는 분에게는 꼭 필요한 내용이라 재 포스팅 합니다.
이 포스트를 통해서 Design Pattern의 두번째 원칙에 대한 오해들을 여러분과 공유하고자 합니다.
문제가 되는 두번째 원칙을 보도록 하죠. 🙂
Favor Object Composition over Class Inheritance
이 말의 의미는 원문 그대로 해석을 한다면 클래스 상속보다는 객체 조합을 선호해라 라는 애기입니다. 대부분의 시중에 나와 있는 책들이 상속보다는 조합을 선호하는 것으로 의미를 파악하고 전달하고 있습니다.
물론 그 당시 CBD가 널리 유행했던 것도 한 몫했죠 🙂 과연 이말이 맞는걸까요?
6년 동안 다양한 패턴에책들을 본 경험을 들어 볼때, 상속이라는 것은 모든 패턴에 사용되고 있었습니다.
거기다 graybox 즉 whitebox(상속)과 blackbox(조합)을 함께 적용하는 것이 패턴계의 철학으로 굳혀져 있어서 과연 이말이 맞는지 많은 의구심을 가지게 되었습니다.
여러분에게 즐거운 소식을 전해드리고자 합니다.
공개되지 않은 EuroPLoP Paper를 발견하게 되었습니다.
자료를 찾았을때 저의 마음을 표현해 주는 그림입니다. 🙂
제가 최근 Patterns for Understanding Frameworks 라는 논문을 정리하고 있는데, 여기에 수많은 Referecne 논문들이 EuroPLoP 최근 논문들이었습니다.
(조만간 이 논문의 정리 버젼이 여러분에게 공개될것 입니다.)
일전에 Dependency에 대한 고찰이라는 글로, Dependency의 종류와 xDepend 툴들을 소개한 적이 있습니다.
이번 POST는 윗 글의 연장선상으로 Dependency 를 해결하기 위한 올바른 설계 방법 몇가지를 소개하고자 합니다.
물론 재미난(?) 그래프로 여러분의 시스템의 Depedency를 파악하는 것을 보여드리고 싶지만.. 모든 일에는 순서가 있는 법. 여러분이 와 닿는 그림과 코드로 간단히 설명드리도록 하겠습니다.
Dependency가 없는 상태로 시스템을 구축한다는 것은 불가능합니다. 재사용의 미덕이 바로 Dependency의 또다른 이름이기도 하죠.
어떻게 하면 Dependency를 잘 관리할수 있을까? 그 해답을 제시해주신 아키텍트를 소개하고자 합니다.
그 분은 바로 Object Mentor의 Robert C. Martin 입니다. Clean Code의 저자로써 알려져 있지만, 사실 이것보다 이름을 더 크게 알리게 한 주역은 패턴의 5가지 법칙(OCP, DIP, LIP, ISP, SRP)입니다.
그런데 이 5원칙의 빛에 가려 숨겨진 Principle이 하나 있는데요. 이름하여 패키지 구조의 원칙들 (Principles of Package Architecture) 입니다.
이 논문에서 Dependency를 깨거나 완화하는 방법들을 여러분에게 소개하고자 합니다.
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를 통해 여러분과 공유하는 시간을 가지고자 합니다.
요즘 소프트웨어가 갈수록 거대해지면서 소프트웨어 통제에 대해 많은 애기를 들을수 있습니다. 그리고 소프트웨어 통제를 들어보신 분이라면, xDepend 라는 툴은 한번쯤 들어보셨을 겁니다.
이번 post는 아키텍쳐 설계시 dependency는 무엇이고 어떠한 종류가 있는지 설명하고, dependency를 관리할때 유용한 Layering과 xdepend 툴에 대해서 소개해 보는 시간을 가지겠습니다.
의존성 (dependency)을 어떻게 관리하느냐에 따라 여러분이 가진 시스템이 쉽게 확장가능한지 (변화에 쉽게 대처 가능한지)를 파악할 수 있으며, 이러한 추세를 반영하여 요즘 쉽게 패키징 할수 있는 단위로 시스템을 구축하는 것에 대해 많은 연구가 진행되어지고 있습니다.
지식을 공유한다는 것은 매우 가치 있는 것입니다. 비록 부족하지만 작은 것 하나 하나 나누다 보면, 작은 것들이 모여 풍성한 지식이 되어, 여러가지 보람을 느끼게 됩니다.
이러한 것이 조그만 저와 저희 팀들의 지식 나눔의 이유 였습니다
하지만 가끔 저와 저희 팀들의 지식의 부족함으로 인해, 실수로 인해 잘못 지식을 전달할 때가 있습니다.
김지선님이 번역해 주시고, 저희 스터디 팀이 몇개월동안 노력해 감수(감역)작업을 펼쳤던 POSA1 권에 대한 오역과 부드럽지 않은 번역으로 인해 승차감이 불편하시다는 피드백을 주셨습니다.
Framework Design Guideline의 저자인 Krzysztof Cwalina의 TechED 2007 Framework Engineering 온라인 세션을 듣고 토론회를 가졌습니다.
편역을 하기전에 Framework 에 관해 배경지식을 쌓고, Paper Meeting 행사를 위한 가이드라인을 만들고 공유하기 위한 목적도 있었습니다.
Krzysztof Cwalina는 실제 .NET Framework를 설계한 분으로, 그의 경험을 책을 통해서 공유했을 뿐만 아니라, FxCop 이라는 툴을 이용해 VS.NET 내부 개발자들의 코드 품질을 검증하는 시스템을 외부로 공개하고 알린 분이기도 합니다.
Framework Engineering은 TechED2007 Europe 에서 발표한 세션으로 원래 일반인에게는 비공개이나, 고맙게도 자신의 블로그를 통해 공유해 주시고 계십니다.
토론을 즐겁게 하기위해서는 어떻게 해야 될까요?
Framework Design Guideline 번역 팀과 TechED 2007에 발표된 Framework Engineering 강의를 듣고 서로 공유하는 시간을 가졌는데요.
함께 재미난 토론 방식을 시도해 보았습니다.
이번 POST는 저희들의 토론 방식을 여러분들고 같이 공유하고자 합니다.
소프트웨어의 현재 상태를 모니터링하거나, 오류시 원인을 파악하기 위해 Log를 남기실 겁니다. 많은 분이 Log4J , Log4NET을 이용하십니다.
하루에 쌓이는 엄청난 로그양때문에, 골치 아프신 경험이 있다면 이 논문을 꼭 읽어 보시길 바랍니다.
이 패턴은 Logging 데이터의 Overflow를 막기 위해 우리가 어떻게 해야되는지 접근 법을 설명하고, Log4XXX(.NET, Java …) 의 내부기능과 비교하여 설명을 합니다.
Architecture 101 