Page History

소프트웨어 설계에 있어서 경험만큼 확실한 것은 없다. 그러나 문제는 모든 사람들이 충분한 경험을 갖고 있지는 않다는 사실이다.

그렇다면 충분한 경험을 갖지 못한 사람들이 많은 경험을 가진 전문가 못지않게 소프트웨어 설계를 잘 할 수 있도록 만들어 줄수 있는 방법은 무엇일까?

소프트웨어 설계 방법론과 지침을 통한 공유

=> 접근의 한계가 있음, 방법론이나 지침은 일반화된 것이어서 구체적인 문제에 적용하기 위해서는 또다른 지식이필요

사례를 통한 공유

=> 사례는 너무 구체적이고 특정 문제의 가정에 의존

위 두가지 모두 한계점이있으며

일반적이지도, 또 너무 구체적이지도 않은 형태의 소프트웨어 설계를 위한 지침을 고민하면서

생긴게 디자인 패턴이다. ( Design Patterns : Elements of Reusable Object-Oriented Software)

- 여기에 포함되는 패턴이 GoF(이분야의 4인방)  디자인 패턴이다.

Erich Gamma외 3명은 다음과 같은 절차로 디자인 패턴을 정립화 하였다.  ( 새로운 디자인 패턴도 아래와같은 과정으로 생겨난다.)

1. 여러가지 설계 사례를 분류
2. 각 유형별로 가장 적합한 설계를 일반화 시켜 패턴으로 정립
3. 이중 다시 쉽게 재사용가능한 객체 지향 개념에 따른 설계만 패턴으로 지정
   
   

디자인 패턴이 휼륭한 원서임에도 불구하고 다음과 같은 약점이 있음

1. 해결하고자하는 문제의 유형이 적고
2. 디자인 패턴이 설계되기까지 어떤 측면에서 고민이 이루어졌는지에대한 유도과정이 확실치 않으며
3. 디자인 패턴에서 제시하는 설계가 일반적인 개발자들의 설계와 비교할때 어떠한 장단점을 가지는지 언급이 안됨

여기까지 Gof 디자인 패턴 이렇게 활용한다 -C++로 배우는 패턴의 이해와활용에서 발췌

그 이후 위 약점을 보완하려고, 다양한 언어로 디자인 패턴 활용방법에 대한 책이 쏟아져 나왔지만

개인적인 디자인패턴에대한 경험은 다음과 같습니다.

1. 바이블 같은책이 없고,개발패턴을 이야하는 사람은 있으나 주위에 잘 활용하는 사람이 없음, 여전히 이해하기 어렵거나, 직접구현해서 적용하기 어려움
2. 결국 사람들이 많이 사용하여 일반화되는 패턴의 특성상  라이브러리화가 되거나 툴킷화되거나 프레임워크에 녹아듬 ( 애매한  라이이브러리-툴킷-프레임워크의 차이 )
3. 패턴을 직접 개발하기보다, 패턴자체가 적용된 개발 라이브러리또는 툴킷을 이용하게 되면서 해당 패턴의 습관이 생김
4. 자신이 사용중인 개발패턴이 무엇이고? 고민하지 않으면? (What-Why-How)  그냥 몸속에 습관으로만 남아있음   

    public class DeepThought
    {
        private int state;

        public int State
        {
            get
            {
                lock (this)
                {
                    Thread.Sleep(3000); //나의 상태에대한 깊은 생각에 빠짐..나는누군가? 여긴어딘가?
                    return state;
                }                
            }

            set
            {
                lock (this)
                {
                    //깊은 생각에 빠질땐 누구도 건들지 말기를 바람,그대가 최고우선순위 스레드라할지라도
                    state = value;
                }                
            }
        }        
    }
var dt = new DeepThought()

Thread.new { console.log( dt.State ) }
Thread.new { dt.State=1 }