패턴을 쓰면 좋은점에 대해 안쓴듯 하여 조금더 써보도록 한다.

결론부터 말하자면 유지보수 관점으로 객체를 설계해야 할경우 패턴을 이용하면 유지보수 관련 포인트를 다수 축소시킬수 있게 된다. 

아래 간단한 예를 들어본다. 

프로그래밍 작업은 곧 데이타 객체들을 조립하여 하나의 프로그램을 만들어내는 것이다. 조립된 형태에 따라 유지보수를 어떻게 할수 있는지가 판가름 나는 것 같다.

 
보통 객체를 생성할때는 특정 객체(Form or UserControl or Class)에서 new 예약어를 통해서 객체를 생성하는데

class {

  ClassType   cObject = new ClassType();
}

형태로 객체를 생성하게 되었을시 해당 객체를 특정사유에 의해 변경하고자 하는 경우 위 소스에서는 선언한 타입과 생성타입 모두 찾아 바꾸어야 한다.
물론 Visual Studio를 이용하면 바꾸는 것도 나름 쉽게 바꿀수 있겠으나 이를 바꾸면서 발생할수 있는 오류에 대한 접근 포인트가 많아 질것이다. 또한 해당 객체를 사용하는데 있어서 메서드등이 특정객체에 종속되는 경향이 있으므로 이 또한 객체와 객체간에 결속력이 강해져서 떼어낼 수 없게 된다. 지금까지 작업들을 보면 떼어낼 일이 거의 없었다. 앞으로도???

 위와 같은 문제애 대한 해결책으로 Interface나 추상객체를 만들어 상속을 통해 객체를 정의 하고 생성하는 경우 선언한 타입이 공통분모가 되면서 바뀌므로 생성타입에 대한 유지보수 관련 포인트가 남게 된다.

 생성타입 객체가 자주 쓰여지는 객체일시 여전히 많은 부분이 손길을 기다리게 되므로 이를 더욱더 축소하기 위한 방법으로
생성패턴을 고려해볼수 있다.

Factory 패턴으로 하자면 
    공통타입 = Factory.Create("타입1");  으로 생성된 객체를 받게 될시엔 사용하는곳 에서의 손볼곳은 거의 없다.
생성하는 위치 곧 Create( string TypeName) 이란 메서드 내부 구현에서 생성되는 객체에 대한 부분만이 유지보수꺼리로 남아 있게 된다. 
 단, 주의 할점은 공통타입이 제공하는 메서드 또는 프로퍼티가 생성되는 객체에 모두 적용되어 있어야 하고 또 사용하는 부분이 객체마다 다를수 있기때문에 이에 대한 정의가 충분히 고려되어야 한다. 이는 추상화 또는 가상메서드를 이용하고 이를 오버라이드 하는 방법으로 해결할수 있다. 여기서 객체의 크기에 대해서는 고려하지 않겠다.

또는 Singleton 패턴으로
    특정객체 = Singleton.GetInstance(); 해서 사용하는 경우도 있는데 싱글톤인 경우는 객체 자체를 유일한놈으로 보고 만들기때문에 이 객체에 대한 접근할수 있는 부분을 최소화 하는 방법이 주요하다.
 DB와 직접 연결되는 통로를 담당하는 객체에 사용해보거나 DebugView용 Form에 적용도 해보았다.

또 Builder 라는 패턴으로
   객체를 생성하는데 있어서 객체들을 조립하는 형태로 만들어내는 패턴이다.

또 자기 상태를 View객체에 직접 알림으로써 변경사항등에 대한 다른 처리등을 유도할수 있는 옵져버,
계층구조를 가지는 데이타를 처리할수 있는 콤보짓트, 비지터, 체인등등... 
  
 어차피 유지보수를 할꺼면 초기 개발에서 좀더 고민하고 고려해서 유지보수 포인트를 줄이는데 힘쓰는게 비용측면에서나 정신적으로나 좋다고 볼수 있다.

 디자인 패턴이란 프로세스를 만들어내기 위해 필요한 객체들을 어떻게 배치하고 조립하느냐에 따른 기술에 대한 명칭일뿐이다. 패턴을 몰라도 이미 사용중에 있을것이며 주로 사용하는 패턴에 대해서 옛날 개발자들이 이름을 붙여놓은 것이다.

 남용하지 말고 적제적소에 쓰면 좋을것이고 또한 사용된 패턴들에 대해 알아야 다른 개발자가 구현한 소스들을 볼수 있게되니 꼭 공부해두는게 좋을듯 하다.