'Dev Note/Design Pattern'에 해당되는 글 2건

  1. 2008.03.10 Anti Pattern 이란 무엇?
  2. 2008.03.09 Design Pattern 이란 무엇인가 ?
Dev Note/Design Pattern2008. 3. 10. 00:33

Anti Pattern 이란 무엇?

Design Pattern이 있고, 그 이면에는 Anti Pattern이 있다.

-- Anti Pattern 이란?
Anti Pattern을 간단히 얘기하면 패턴과 반대로 프로그래밍을 하는 과정에서 프로그래머들이 흔히 범하기 쉬운 바람직하지 않은 방법들과 그로 인한 폐해를 의미한다.

Design Pattern의 출현은 프로그래머들에게 지금까지 있었던 가장 효과적인 가이드 라인을 제공해 주었다. 이들 패턴들은 개발 중에 나타나는 복잡한 구조와 문제들을 정리해 주었고, 소프트웨어 개발을 편리하게 도와주는 방안도 다양하게 개발되어 왔다. 그러나, 이들을 도입하여도 프로젝트는의 상황은 반드시 좋아지는 것은 아니다. 많은 단체 또는 개인이 창의적이고 혁신적인 방법을 개발하여 제공하여도 소프트웨어 개발의 성공 가능성은 낮은 것이 현실이다.

수많은 소프트웨어 개발 프로젝트가 진행이 된다. 그러나 그 수많은 프로젝트 중 거의 대부분이 취소되거나, 최초 예상했던 예산과 기간보다 더 많은 비용이 투입된다. 많은 프로젝트의 실패들과 옳바르지 못한 개발 산출물들은 성공한 프로젝트의 것과 마찬가지로 아주 중요한 가치를 지니는데, 왜냐하면 이것들이 모든 프로그래머들에게 가지지 말아야 할 방향들을 알려주고 있기 때문이다. 이들이 바로 Anti Pattern 이다.

-- Anti Pattern이 발생하는 측면

  1. 관리상의 Anti Pattern : 프로젝트의 프로세스와 프로젝트 구성원의 잘못된 관리
  2. 아키텍쳐 상의 Anti Pattern : 설계와 구조상의 잘못 된 정의
  3. Object 설계 Anti Pattern : Object를 설계상의 잘못 된 정의
  4. 방법론 상의 Anti Pattern : 개발 방법론 상의 절못 된 정의 또는 잘못 된 진행
  5. 설정관리 상의 Anti Pattern : Version 또는 Configuration 관리 상의 잘못 된 정의
  6. 개발상의 Anti Pattern : 코드 상의 잘못 된 사례

-- 잘 알려진 Anti Pattern

  1. 스파게티 코드 (Spaghetti Code - 개발) : 개발과정에서 다양한 기능들을 추가 또는 유지보수에 의해 코드가 복잡하게 꼬여 버린다.
  2. 스토브 파이프 시스템 (Stovepipe System - 아키텍쳐) : 다양한 솔루션들을 확실한 추상화의 개념 없이 임의로 묶어 하나의 제품을 만들면 신뢰성이 떨어지며 유지보수가 힘든 제품이 탄생된다.
  3. 분석 마비 (Analysis Paralysis - 관리) : 분석 단계에서 완벽하고 완전한 분석을 꿈꾸면 이는 소프트웨어 개발 진행을 마비 시켜 버린다.
  4. 신의 객체 (God Object - Object 설계) : 하나의 객체에 너무 많은 기능과 인터페이스를 담아버리면 복잡하고 유지보수하기 힘들고 상호 의존성이 높은 클래스가 탄생된다.
  5. Singletonitis (Object 설계) : Singleton Pattern의 불필요하게 남용
  6. Yo-yo Problem(Object 설계) : 구조를 지나치게 분리하게 되면, 더욱 이해하기 힘든 구조가 된다. 
  7. Action at a Distance (개발) : 예상되지 않은 상호작용은 시스템을 광범위하게 구분해 버린다. 
  8. 변조 된 요구사항 (Phony Requirements - 아키텍쳐) : 프로젝트에서 모든 요구사항이 문서로 상세화 되지 않고, 유선이나 개개인의 구두로 전달이 된다면 변조(허위) 된 요구사항이 발생된다.
  9. 애매한 관점 (Ambiguous Viewpoint - 개발) : 명확하지 않은 관점에서 모델링을 수행하면 객체 모델링에서 객체들을 정확하게 정의 할 수 없다.
이상 Anti Pattern에 대해 간략하게 알아봤는데, 추가로 Anti Pattern에 대해 좀더 이해하고, 이를 개발과정에 반영하기를 원한다면 다음의 책들을 참조하기 바란다.

Anti Pattern wiki article : http://en.wikipedia.org/wiki/Anti-pattern
Anti Patterns : Refactoring Software, Architectures, and Projects in Crisis,1998 by William J.Brown & …
Anti Patterns and Patterns in Software Configuration Management, 1998 by William J.Brown & …
Posted by as.wind.914
Dev Note/Design Pattern2008. 3. 9. 17:41

Design Pattern 이란 무엇인가 ?

Design Pattern 카테고리에서는 Design Pattern이란 무엇이며, 현재 개발자들이 많이 사용하고 있는 Design Pattern에 대해서 다뤄볼 것이다. 먼저 Design Pattern들을 소개하기 앞서 Design Pattern 이란 무엇이며, 왜 사용을 해야 하는지 등을 간단히 소개하고 넘어간다.

-- Design Pattern 이란 무엇인가 ?
프로그래밍을 작성할 때 프로그래머라면 누구나가 많은 것을 고민하고 생각하는 것들이 있을 것이다.  수 많은 프로그래머들이 있었고 그들은 유사한 문제점에 대한 해결책 또는 대안을 나름대로 고민하여 해결했을 것이다. 그리고, 다른 프로그래머 또는 잘 만들어진 프로그램의 좋은 소스 코드들을 참조하고 그들이 많은 시간을 들여 구현한  프로그램의 구조를 자신들의 코드에 반영하고 싶어한다.

좋은 코드를 참조하면 좋은 코드를 만들 수 있다는 것은 당연한 진리이다. 그러나, 진정으로 좋은 코드는 쉽게 접할 수가 없고, 접한다고 해도 그 코드를 구조를 파악하고 코드에 담긴 철학을 이해하기에는 너무나 많은 시간이 소비된다. 그러면, 프로그래머들이 서로의 좋은 기법을 참조하고 사용할 방법은 없는 것인가? 객체 지향 프로그래밍에서 가장 중요하게 여겨지는 것이 "코드의 재활용성"에 있음에도 불구하고, 다른 이들의 코드와 구조를 왜 그리도 참고하기 힘든 것인가?

프로그래머가 어떠한 시스템을 개발해야 한다면, 시스템 구현에 있어서 시스템의 구성, 리소스의 처리 등 구현 초기의 사상들을 어떻게 구조화 할 것인가? 구현 후 요구사항의 추가 또는 변경 등이 발생 했을 때 그 부분들을 어떻게 잘 수용할 것인가? 이런 수많은 난제들이 프로그래머들 앞에 도사리고 있는데 대체 어떻게 헤쳐나갈 것 인가?
그건 Design Pattern이 이런 수많은 난제들을 직접적으로 해결해 준다. 시스템의 구현시 구조를 이렇게 가져가면 효과적이면 추후 확장 가능한가에 대한 해답을 클래스 들의 구현방법으로 제시해 준다.

Design Pattern을 공부한다는 것은 훌륭한 프로그래머의 좋은 디자인 형태는 배우는 것이라 생각된다. 프로그래머들이 향후 2~3년후에 시행착오로 알아낼 지식을 Design Pattern을 공부함으로써 그 기간을 앞질러 나갈 수 있는 것이다. 훌륭한 디자인 형태를 공부해 둠으로써 자신의 코드를 좀더 좋게 다듬을 수 있으며, 이러한 자신의 코드들이 모여 전체 시스템의 품질이 향상될 수 있다는 것이다.

Design Pattern의 종류와 구조를 이해하고 암기하는 것은 어려운 일이 아니다. 이것은 시간만 들이면 다 할 수 있는 일이다. 실제로 어려운 일은 프로그래머가 접하는 문제에 자신이 습득한 Design Pattern을 적절하게 적용하는 일이다. Design Pattern이 실제 적용 될 때는 여러 패턴이 혼합되어 적용되며 또한 거의 대부분의 패턴들이 약간씩이나마 변형되어 적용되게 된다. 그리고 꼭 명심해야 할 것은 무리한 패턴의 적용과 잘 못된 패턴의 적용했을 때의 부작용도 항상 염두해 두어야 한다.

-- Design Pattern은 변화 대비
프로그래머가 구현 할 시스템의 요구사항의 변화가 없고, 구현 후 변경사항이 없다면 굳이 Design Pattern을 적용할 필요는 없다. 그러나 실제 개발되는 대부분의 시스템들은 구현 후 긴 기간을 유지보수 기간을 가진다. 요구사항은 개발 후 변경은 말할 것도 없고, 개발기간에도 심없이 변경이 된다. 코딩 중에도 요구사항의 잘 못된 점을 변결하고 변경하야 하는 경우도 발생을 한다. 그래서 프로그래머들은 요구사항의 변화에 익숙해져야 하며, 변화에 대비하여 디자인해야 한다. 프로그래머의 경력은 이런것이 녹아있는 것이 아닌가 싶다. 경험 많은 프로그래머들은 항상 자신의 코드를 추상하하고, 일반적으로 만들려고 노력들을 한다. Design Pattern은 변화에 따른 변경되어야 하는 코드들을 최소화시켜준다. 지금까지 알려진 Design Pattern들을 하나 하나 유심히 보면 모든 Design Pattern의 초점은 "변화"라는 것을 파악할 수 있을 것이다.

-- Design Pattern을 적용할때 중요한 규칙
지금까지 소개 된 Design Pattern을 유심히 보면 공통 된 규칙이 존재한다는 것을 알수있다.

- 구현 클래스가 아닌 추상화 된 인터페이스로 프로그래밍하자.
 
사용자 삽입 이미지

[ Interface 바탕으로 하는 클래스 호출 ]


DataTranslator Object는 EnglishTranslatorImpl을 직접 바라보는 것이 아니라 항상 추상화 된 Translator(Interface)를 통해 보도록 한다. 실제 구현체인 EnglishTranslatorImpl이 변경되더라도 그를 사용하고 있는 Object(DataTranslator)는 영향을 받지 않도록 하기 위해서이다. Interface(Translator)는 가급적 변화되지 않게 일반적으로 추상화를 시켜야 한다.
모든 구현을 Interface를 통할 필요는 없다. 그러나, 복잡한 비즈니스 로직을 담고 있거나, 변경이 잦은 객체인 경우는 Interface를 가져가는 것이 시간이 흐를수록 좋다는 것을 느끼게 될 것이다.

- 상속(Inheritance)이 아니라 Delegation을 사용한다.
 
사용자 삽입 이미지

[ 상속 (Inheritance) ]

상속은 OOP의 기본 개념이다. 그런데 상속을 사용하지 말라는 것은 뭔 말인가? 상속은 공통 된 특징을 Super Class에 정의를 하여 하위 클래스까지 사용을 하게 된다. 그러나 Sub Class 입장에서 보면 불필요한 속성이나 메소드가 단지 Super Class에 존재한다는 사실만으로 접근 가능하게 되어 버리는 경우가 있다. 즉 Sub Class와 Super Class의 구조가 컴파일시에 서로 엮이게 되어 Runtime 시에는 이를 바꿀 수가 없다는 것이다.
 
사용자 삽입 이미지

[ Delegation ]

Delegation은 Super Class가 내부 필드로 존재하게 되고 필요할 때마다 이 필드에 접근하여 사용하게 된다. 이렇게 되면 Runtime 시에 내부 필드를 자유롭게 바꿀 수 있게 되어 해당 필드를 접근함으로써 얻어지는 행위 또한 바뀌게 된다. 즉 Delegation을 통해 Runtime시의 행위가 바뀌게 되는 것이 최대 이점인 것이다.

- Coupling을 최소화함으로써 추후의 변화를 최소화한다.
어느 하나의 Object의 기능 변화가 전체 클래스 구조를 바꾸거나 혹은 많은 부분에 걸쳐 변화를 야기한다면 뭔가 객체설계가 잘 못 되어진 것이다. 그리고 여러 부분을 중복되서 수정하고 있다면 이 또한 뭔가 잘 못 되었다는 것이다. 모든 디자인 패턴들이 일관되게 말하는 것은 "Coupling을 최소화하라"이다.
Posted by as.wind.914

티스토리툴바