프로그래밍 디자인패턴에 대해 알기쉽게 정리된 네이버지식인에서 발췌..

프로그래밍에서도 발생하는 '비슷'한 문제상황들을 추상화해서 각각의 비슷한 문제상황들에 등장할법한 객체들을 설정하고 그 객체들끼리의 관계를 정의한게 바로 디자인 패턴입니다. ^^

 

그러니까 하나의 디자인 패턴은 이 패턴이 사용되는 문제상황이 비슷비슷합니다. 상황이 비슷하니까 접근 방법, 해결방법도 비슷합니다..^^

 

알고리즘도  비슷한 프로그래밍 상황에서 사용되는 방법이니까 추상화, 일반화라는 점에서 어느정도 디자인 패턴과 성격이 비슷하지만(복사-붙여넣기-약간수정), 알고리즘은 '효율성'에 관심이 있습니다. 현재의 시스템 상황에서 우리가 선택할 수 있는 가장 효율적(빨리 계산, 공간을 덜차지)인 문제해결 방법이 무엇인가에 관심이 있을 뿐, 객체간의 관계는 알고리즘에서 고려대상이 아닙니다. ^^

 

중요한 것은 디자인패턴은 OOP(객체지향)와 밀접한 관련이 있다는 것이고 알고리즘은 객체지향이든 구조적프로그래밍(C언어같은 스타일)이든 프로그래밍 방식과는 상관이 없다는 점입니다. 왜냐하면 알고리즘이란 대부분 함수(메소드) 안에서 구현이 되고 함수는 자바이든, c이든 c++ 이든 비쥬얼베이직이든 다 존재하는 프로그램의 기본단위이기때문입니다.^^ 

 

디자인패턴은 각각의 함수(메소드)가 어떻게 구현되었는지에 대해서 관심이 없습니다. 단지 '이 메소드는 이러이러한 일을 하게 된다' 라고 성격을 규정해주고 그러한 메소드들을 통해서 객체들끼리의 관계가 설정되거든요.(메소드가 다른 객체를 참조하거나, 생성해서 잠시 사용하거나 하는 식으로 관계가 설정됨). 따라서 디자인패턴에 의해서 메소드의 성격이 규정되면 그 성격을 실제로 구현하기 위해서 가장 효율적인 알고리즘을 선택하는 일이 있을 수 있겠죠 ^^

 

콩쥐팥쥐와 신데렐라의 이야기를 떠올리면서 그안에 어떠한 공통의 패턴이 존재하고 어떠한 알고리즘이 존재하는지 살펴보는 것도 재미있을 것 같군요 ^^

 

 

* 위에서는 제가 이해를 돕기 위해서 기승전결이라는 큰 테두리를 말씀드렸는데, 디자인 패턴은 프로그램 전체에 적용되는 큰 테두리가 아니라는 점을 덧붙입니다. 큰 테두리를 규정하는 것은 아키텍쳐로 알고 있습니다.

 

콩쥐팥쥐나 신데렐라나 계모의 구박을 견뎌내고 해패엔딩으로 끝난다 라는게 큰 테두리이고 잔치에 못가도록 구멍난 독에 물을 채우라고 하는 것과 엄청난 양의 집안일을 맡겨놓고 파티에 가는 것, 그리고 그때 결정적으로 도와주는 자가 등장한다는 점은 디자인패턴에 해당합니다. ^^

 

전체 테두리에서 일어나는 그때그때의 상황들 -> 디자인패턴이 해결할 부분

 

이라는 점을 기억해주세요 ^^

http://kin.naver.com/detail/detail.php?d1id=1&dir_id=10106&eid=WY5EdVDjZRgbMHEwnSo8a4jyLycAhR4P&qb=7ZSE66Gc6re4656Y67CNIOuUlOyekOyduO2MqO2EtA==&enc=utf8&section=kin&rank=3&sort=0&spq=0&pid=fo48bz331zZsss4l7uhssv--423007&sid=SoI45BAygkoAADLqP4U