서언

왜 디자인 패턴을 배워야 하는가?

1.개발은 혼자 하는게 아니라 팀단위로 이루어지고 설계 당시에 개발자 간의 대화(Communication)을 위해서 배워야 한다.
2.선배 개발자들의 노하우가 축적되어 있기 때문에 동일한 시행착오를 거칠 가능성이 적다.

그렇다면 디자인 패턴이란 무었인가?

말그대로 설계 할때 반복적으로 나타나는 것들의 모음 이다.

보통 소프트웨어 개발은 분석->설계->개발->테스트 의 과정을 거치게 되는데 이중 설계단계에 적용하는 것이 디자인 패턴이다.

하지만 실제 프로젝트에서 설계를 제대로 하지 않기 때문에 개발단계에서 리펙토링을 통해 디자인 패턴의 내용들이 구현되는 경우가 흔히 있다.

또한 , 이와 반하는 개발 방법론 들이 많이 나와있다. (Agile Development, Test Driven Development ) 등등..

물론 TDD의 위주로 보면 설계가 거의 없어도 되겠지만 실제 TDD를 하다 보면 리펙토링이 엄청나게 들어가고 또한 TDD 를 하는 사람의 지식도 상당히 중요하다. 초보가 할수 있는부분은 아니다.

XP란 녀석도 있는데 10~20명의 소단위 프로젝트나 작은 단위의 프로젝트에서 쓰기 적합한 방법론이다.

실제 100~500명 규모의 프로젝트에서는 대부분 RUP 이나 Spiral 모델을 변형한 방법론을 접목하여 사용한다.



다음내용은 스크랩한 부분입니다.

패턴의 설명을 일축할때 신상호님이 말했던 '패턴은 우라다'란 명언을 사용합니다. 패턴은 흔히 반복적으로 발생하는 일반적인 문제와 요구영역에서 해결책을 인도하고 있습니다.

이제와서 패턴을 디자인의 관점으로만 보지 않습니다. 물론 상당부분 디자인의 문제를 포함하고 있지만 POSA 1(Pattern Oriented Software Architecture)[1]의 분류처럼 Architecture, Design, Idiom의 단계와 범위에 따라 분류하기도 하고 Process Pattern[2]이나 Analysis Pattern[3]에서 처럼 소프트웨어 공정과정에서 패턴을 적용하기도 합니다.

좀 더 영역을 확대한다면 형태화 행동을 갖는 모든 것이 패턴일 수 있습니다. 그런 의미에서 가라데의 형이나 태권도의 품세, 태극권의 식(式)은 유명한 패턴이라 할 수 있습니다.

무엇보다도 패턴을 간단명료하게 설명하기위해선 패턴의 아버지인 알렉산더의 말을 빼놓을 수가 없습니다.

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”- Christopher Alexander [AIS+77]


하지만 패턴이란 무공을 펼치는 것은 쉽지 않습니다. 그것은 당구에서 맛세이(=찍어치기)를 하기 위해서 300 다마 정도 되어야 하는 것과 같습니다. 아무나 당구공을 찍어칠 수 있지만 찍어칠 때를 구분하는 것과 때를 안다 하더라도 적절히 적용하기란 아무나 할 수 없죠... 그래서 Fowler는 패턴을 '반쯤 익은 빵'으로 비유합니다. 나머지 반은 내가 지지고 볶아야한다는 거져...

여기에 패턴의 위력과 허수가 존재합니다. customizing해야만 쓸 수 있는거져... 왜냐하면 패턴은 일반적인 내용을 말하지만 나의 컨텍스트는 일반적이지 않기 때문이죠.. (참고로 패턴적용시에 도움이 되는 항목은 - GoF 분류법 기준으로 - Applicability, Consequences, Implementation이 있습니다. 어떤 경우 Structure와 Sample Code는 더욱 혼선을 가져오기도 합니다.)

본인도 그러하거니와 패턴을 적용해서 패턴을 욕하는 대부분의 사례가 이 허수에 빠지는 것입니다. 적용할 경우와 적용법을 모르고 Structure로 대들었을 때죠..


기계론적 세계관에 대한 회의...

근래들어 패턴의 이런 모습에 회의를 느꼈습니다. 사실 패턴 뿐만 아니라 Software Engineering에 대한 회의인데요.. '적용자에 따라 결과가 달라진다면 '공학적'이라 할 수 없다. 적어도 공학이라 한다면 A가 해도 B가 해도 똑같은 결과가 나와야하지 않은가?'란 내용입니다. Software Engineering적 접근은 모든 경우의 수를 predictable할 수 있거나 그렇지 않다면 모든 것을 해치울 수 있는 준비에 그 목적이 있다고 할 수 있습니다. 다분히 공학적이고 기계론적이죠..
하지만 대부분 '모든 것'에 대한 범위나 정도 설정은 겪고나서 정의/해석하게 됩니다.
이런 맥락에서 Software Engineering은 Software Engineering Oriented의 성격이 강합니다. 근대에 이르러 뉴튼과 칸트의 출현은 모든 기계론적 세계관을 일단락했습니다. 인간의 모든 성격을 오성으로 표현할 수 있으며 떨어지는 사과 하나도 역학으로 충분한 설명이 가능합니다. 이런 가정과 전제에서 인간의 인생까지도 기계론적으로 설명 가능합니다. 그래서 기계론을 결정론이라고 부르기도 합니다만...

사실 Software Engineering의 패러다임들은 인문학과 다른 학문의 그것을 많이 차용한 듯 합니다. 50년을 조금 넘는 역사의 문제가 크겠지만 적어도 그것을 능가할 수 없는 무엇이 아쉽습니다. 더구나 Software Engineering 노력이 칸트나 뉴튼이 완결한 세계관에 이르지도 못 한다는게 거듭 아쉽습니다.

다시 패턴의 문제로 돌아가서 패턴은 이런 Software Engineering의 성격을 그대로, 정확히 반영하고 있습니다. 근래들어 전술한 생각과 함께 들었던 회의는 패턴이란 현상의 원리를 정의하는건데 본질에 미치지 않나 싶습니다. 다시 말하자면 패턴이란 반복적이고 유사한 현상에 대한 설명일 뿐이지 본질은 아니지 않는가? - 사실 이 논의를 위해선 현상과 본질, 그리고 원리에 대한 심도있는 개념정리가 필요하겠지만 일단은 유보하겠습니다.
아마도 이 본질, 즉 원리안에 원리가 밝혀진다면 구력 30과 500이 같이 맛세이를 쳐도 같은 결과가 오지 않을까?


[1] Pattern-Oriented Software Architecture, Volume 1: A System of Patterns by Frank Buschmann (Author), Regine Meunier (Author), Hans Rohnert (Author), Peter Sommerlad (Author), Michael Stal (Author)

[2] Process Patterns, :  http://www.bell-labs.com/user/cope/Patterns/Process/index.html

[3] Analysis Pattern, Reusable Object Models (Object-Oriented Software Engineering Series) -- by Martin Fowler; Hardcover
신고
top

Write a comment


▶ 디자인 패턴 적용시 중요한 세가지 규칙

1. Implementation class 가 아닌 interface 를 이용 하는게 좋다.

2. Inheritance 가 아닌 Delegation 을 사용

    public interface AA {
        public String getInfo();
    }
    public class Super implements AA {
        public String getInfo() {}
    }
    public class Sub {
        AA delegator;
        public void test() {
            delegator.getInfo();
        }
    }

cf ) white-box reuse : Inheritance vs. black-box reuse : Delegation

물론 상속을 사용하여하는 경우도 있다.

3. Coupling 의 최소화
* 커플링 : 어느 하나의 기능 변화가 전체 시스템의 구조에 영향을 미치는 정도
> 이것이 커질수록 잘못된 디자인

>> Refactoring 과 design pattern
    > 실제 문제 분석이 종료된 이후 좀더 효율적인 코드로 변화시키는 것을 refactoring 이라 한다.
    > 이 과정에서 디자인패턴이 적용되어지는 경우가 많다
    > 구현하기 이전에 보지 못했던 디자인상의 문제점들을 실제 구현에 들어가 이를 개선하는 것

리펙토링에 관련된 책은 마틴 파울러의 리펙토링이라는 책이 번역되어 출판되어 있다.
>> Anti-Pattern
> s/w 를 만드는 과정에서 쉽게 도출되는 바람직하지 않은 방법들

> 종류
    - 관리상의 안티
    - architecture 상의 안티
    - 개발상의 안티
> 대표적인 anti-pattern
    - Spaghetti code : 개발과정에서 나타남.  기능의 추가로 인해 코드의 복잡도가 증가, 꼬이는 현상
    - Stovepipe System : architecture의 문제, 확실한 추상화가 없이 하나로 묶어 제품을 만드는 경우
    신뢰성, 유지보수가 모두 저하
    - Analysis Paralysis : 분석단계에서 너무 완벽함을 추구하다보면 개발 진행 자체가 마비
    - Swiss Army Knife :  architecture 작성시 하나의 객체에 너무 많은 기능/인터페이스를 넣는 경우 복잡,
    유지보수 난이, 커플링 증가
    - Ambiguous Viewpoint : 불명확한 상태에서 모델링을 진행 -> 객체의 불명확
신고
top

Write a comment