프로그래밍을 공부하면서 "디자인 패턴"이라는 것을 한번쯤은 들어 봤을 거에요.
한번도 들어 보지 못했다면... 그리고 내가 전문 프로그래머가 될 것이라면 꼭 찾아봤으면 해요.
왜냐고요? 이것이 무엇인지 모르고 활용할 수도 없으면 결코 뛰어난 프로그래머의 반열에 들어 슬 수 없어요.
어떤 천재는 객체 지향 언어 문법책만을 보고 객체 지향 설계를 배울 필요도 없는 사람도 있을 수도 있겠지만...
난 22년을 프로그래머로 일했지만 단 한번도 이런 사람을 보지도 듣지도 못했거든요.
디자인 패턴은 무엇인가?
"디자인 패턴"은 객체 지향 패러다음 관점으로 전문가들의 경험을 카탈로그 형식으로 기록한 객체 지향 설계 기법들이예요. 디자인 패턴의 중심에는 객체 지향 설계가 있어요.
객체 지향 언어는 프로그래밍 언어에서 가장큰 주류이고 대세 언어이지요.
프로그래머라고 불리는 사람들은 모두들 객체 지향 언어를 자유 자제로 다루는 사람들이니까요.
함수 지향 언어도 최근 5년사이에 붐이 되었고 병렬 및 분산처리에 적함하여 새로운 패러다임으로 제시되고 있지요. 그렇지만 아직까지는 현실의 사물표현과 가장 근접하고 인간의 사고 방식과 흡사한 객체 지향 패러다임은 앞으로도 수십년 간은 계속 지속하고 발전할 거예요.
프로그래머로서 회사를 다니는 사람이라면 수십년 경력을 가진 선배중에 뛰어나다고 인정 받는 프로그래머를 경험해본적이 있을 거예요. 이런 분들을 전문가라고 부르겠습니다.
이러한 전문가들은 어떤 프레임워크를 개발할때 처음 부터 시작하는 것이 아니라 자신의 경험들을 통해 구현 방법을 찾아내고 사용했던 해결책들을 다시 사용하지요. 전문가들은 많은 객체 지향 시스템에서 클래스 패턴이나 객체들 간의 상호 작용 방식이 반복됨을 알고 있어요. 이러한 소프트웨어 설계에서 얻은 세세한 경험들을 카탈로그 형식으로 기록한 것이 "디자인 패턴"이예요.
디자인 패턴을 왜 알아야 하나?
"디자인 패턴"을 알면 공통의 이름으로 의사 소통 할 수 있어요.
카페에 가서 주문 할때 "원두를 갈아서 뜨거운 물로 이 원두를 내려서 우유를 넣고 얼음을 띄운 음료를 주세요."라고 주문하나요? 이렇게 주문하는 것이 아니라 "아이스 아메리카노 라떼 주세요."라고 하죠.
카페 뿌문 아니라 식당에서도 첫번째 주문의 예처럼 주문을 한다고 생각하면 어떨까하면서 살며서 미소를 띄워보네요.
느림의 미학이라고 어쩌면 더 재미있고... 나름 좋을 것 같기도 하고요. :)
프로그래밍도 같아요 프로그래밍을 어떻게 할지 의사 소통 할때 객체를 어떻게 구조화 할지 공통의 언어로 간단히 소통 할 수 있어요.
예를 들어 격투 게임을 만들어 한다고 생각 한다면, 두 명의 프로그래머가 다음과 같은 대화를 누굴 거예요.
A : Command pattern으로 입력에 대한 명령 처리를 하고 캐릭터 생성은 Factory method pattern사용하고 캐릭터 전투시에는 Strategy pattern으로 각 캐릭터의 행동을 구현 하면 좋겠어.
B : 캐릭터들은 한번 만들어지면 그 행동이 많이 변할 것 같지 않아서 Strategy pattern 보다는 Template method pattern으로 구현하여 좀더 단순하게 만들자. 그리고 캐릭터들의 애니메이션 처리를 위해서는 State pattern을 사용하면 간결하게 구현 할 수 있겠어.
디자인 패턴을 모르시는 분은 이 대화를 듣고... "아~~~ 이게 무슨 소리인가???" 멘붕이 오겠죠.
나름 프로그래밍 잘 하는 프로그래머라고 자부 하고 있었는데... "으~~~ 악~~~"하며 마음속으로 이런 소리를 내겠죠.
디자인 패턴을 모르는 두 프로그머자 구현 방법을 논의 할때 이러한 방법으로 소통하지 않는다면 대화해야할 내용은 10배 이상이고 이해 시키기 위해 클래스 다이어그램과 화이트 보드가 빼곡할 정도로 객체를 그리고 관계를 설명해야 겠지요. 너무나도 비효율 적입니다.
디자인 패턴 용어로 소통 하는 것은 멋있어 보이고 자극을 줍니다.
이는 당연한 것이지요. 하나도 못 알아 듣고 멋있어 보이고 뭔가 나랑 다른 레벨의 사람들의 대화로 느껴질테니 까요.
소프트웨어 개발 실무자들의 전문성을 문서화 한 것이며 공통의 설계 어휘이지요.
생각 해보면 어떠한 알고리즘, 자료구조에는 이름을 지었지요. 퀵소트, 피타고라스 정리, A*, 하면서 "디자인 패턴"이라는 것을 한번쯤은 들어 봤을 거에요.
한번도 들어 보지 못했다면... 그리고 내가 전문 프로그래머가 될 것이라면 꼭 찾아봤으면 해요.
왜냐고요? 이것이 무엇인지 모르고 활용할 수도 없으면 결코 뛰어난 프로그래머의 반열에 들어 슬 수 없어요.
난~ 그 딴거 없어도 프로그램을 잘만 짜는데 무슨 소리냐고요?
이러한 생각의 나만의 생각이 아니라 전 세계 유명한 구루들의 일관된 생각이라고요.
어떤 천재는 객체 지향 언어 문법책만을 보고 객체 지향 설계를 배울 필요도 없는 사람도 있을 수도 있겠지만...
난 22년을 프로그래머로 일했지만 단 한번도 이런 사람을 본적이 없지요. 다른 선배 프로그래머들에게도 들은바 없고요.
어쨌든 제가 아는한 없어요.
본론으로 들어 가기존에 잡설이 길었죠? ㅎㅎ
디자인 패턴은 무엇인가?
"디자인 패턴"은 객체 지향 패러다음 관점으로 전문가들의 경험을 카탈로그 형식으로 기록한 객체 지향 설계 기법들이예요. 디자인 패턴의 중심에는 객체 지향 설계가 있어요.
객체 지향 언어는 프로그래밍 언어에서 가장큰 주류이고 대세 언어이지요.
프로그래머라고 불리는 사람들은 모두들 객체 지향 언어를 자유 자제로 다루는 사람들이니까요.
함수 지향 언어도 최근 5년사이에 붐이 되었고 병렬 및 분산처리에 적함하여 새로운 패러다임으로 제시되고 있지요. 그렇지만 아직까지는 현실의 사물표현과 가장 근접하고 인간의 사고 방식과 흡사한 객체 지향 패러다임은 앞으로도 수십년 간은 계속 지속하고 발전할 거예요.
프로그래머로서 회사를 다니는 사람이라면 수십년 경력을 가진 선배중에 뛰어나다고 인정 받는 프로그래머를 경험해본적이 있을 거예요. 이런 분들을 전문가라고 부르겠습니다.
이러한 전문가들은 어떤 프레임워크를 개발할때 처음 부터 시작하는 것이 아니라 자신의 경험들을 통해 구현 방법을 찾아내고 사용했던 해결책들을 다시 사용하지요. 전문가들은 많은 객체 지향 시스템에서 클래스 패턴이나 객체들 간의 상호 작용 방식이 반복됨을 알고 있어요. 이러한 소프트웨어 설계에서 얻은 세세한 경험들을 카탈로그 형식으로 기록한 것이 "디자인 패턴"이예요.
디자인 패턴을 왜 알아야 하나?
"디자인 패턴"을 알면 공통의 이름으로 의사 소통 할 수 있어요.
카페에 가서 주문 할때 "원두를 갈아서 뜨거운 물로 이 원두를 내려서 우유를 넣고 얼음을 띄운 음료를 주세요."라고 주문하나요? 이렇게 주문하는 것이 아니라 "아이스 아메리카노 라떼 주세요."라고 하죠.
카페 뿌문 아니라 식당에서도 첫번째 주문의 예처럼 주문을 한다고 생각하면 어떨까하면서 살며서 미소를 띄워보네요.
느림의 미학이라고 어쩌면 더 재미있고... 나름 좋을 것 같기도 하고요. :)
프로그래밍도 같아요 프로그래밍을 어떻게 할지 의사 소통 할때 객체를 어떻게 구조화 할지 공통의 언어로 간단히 소통 할 수 있어요.
예를 들어 격투 게임을 만들어 한다고 생각 한다면, 두 명의 프로그래머가 다음과 같은 대화를 누굴 거예요.
A : Command pattern으로 입력에 대한 명령 처리를 하고 캐릭터 생성은 Factory method pattern사용하고 캐릭터 전투시에는 Strategy pattern으로 각 캐릭터의 행동을 구현 하면 좋겠어.
B : 그런데 말이야 캐릭터는 한번 만들어지만 그 행동이 많이 변할 것 같지 않아서 Strategy pattern 보다는 Template method pattern이면 충분 할 것 같으니 좀더 단순하게 만들자. 그리고 캐릭터들의 애니메이션 처리를 위해서는 State pattern을 사용하면 간결하게 구현 할 수 있겠어.
디자인 패턴을 모르시는 분은 이 대화를 듣고... "아~~~ 이게 무슨 소리인가???" 멘붕이 오겠죠.
나름 프로그래밍 잘 하는 프로그래머라고 자부 하고 있었는데... "으~~~ 악~~~"하며 마음속으로 이런 소리를 내겠죠.
디자인 패턴을 모르는 두 프로그머자 구현 방법을 논의 할때 이러한 방법으로 소통하지 않는다면 대화해야할 내용은 10배 이상이고 이해 시키기 위해 클래스 다이어그램과 화이트 보드가 빼곡할 정도로 객체를 그리고 관계를 설명해야 겠지요. 너무나도 비효율 적입니다.
디자인 패턴 용어로 소통 하는 것은 멋있어 보이고 자극을 줍니다.
이는 당연한 것이지요. 하나도 못 알아 듣고 멋있어 보이고 뭔가 나랑 다른 레벨의 사람들의 대화로 느껴질테니 까요.
소프트웨어 개발 실무자들의 전문성을 문서화오리 한 것이며 공통의 설계 어휘이지요.
생각 해보면 어떠한 알고리즘, 자료구조에는 이름을 지었지요. 예를 들어 퀵소트, 피타고라스 정리, A*, 오일러 공식, 상대성 이론 등등... 수도 없이 이름을 지었고 이 이름을 부르기만 해도 아주 많은 공식과 개념들이 머리속에 형상화 됩니다. 디자인 패턴도 동일합니다. 즐겨 사용하고 유용한 객체 지향 구성 방법에 이름을 지어 준 것이지요.
최근에 본 아스달 연대기의 대사가 생각나에요. "나~ 탄야 너희들에게 이름을 지어 주니 무엇이든 될 수 있는 밝은 별이 되라고 하여 백성이라 부른다". 의미를 부여하고 이름을 붙여 모두 함께 부르는 것이 얼마나 큰 의미가 있고 얼마나 큰 힘이 있는지 새삼 생각하게 됩니다.
객체 지향 원칙 중에 리스코프 치환의 법칙이라고 있는데 내용을 별것도 아닌데 리스코프라는 이름이 전세계 프로그머에 의해 불려지고 있죠. 부럽네요~. 이 얘기를 하는 이유는 이 글을 보는 어떤 분이라도 새로운 디자인 패턴을 만들고 알린다면 자신의 이름을 많은 사람들이 부르게 할 있는 거죠. 예를 들어 "God jino pattern"과 같이요.
패턴 이름을 부르는 것만으로 끝나는 것이 아니라 이 패턴의 구조와 용법 그리고 구현 방법들이 함께 떠오르고 심지어는 jino라는 사람에 대해서도 떠올리는 프로그래머가 있겠죠.
복잡한 내용들을 추상화된 패턴 개념의 이름으로 부른다면 복잡도를 줄일 수 있고 이해하기 쉽지요.
마지막으로 객체지향 학습도구가 되지요. 객체지향 사고를 배우는데 많은 도움이 됩니다.
훌륭한 설계자로 만들어 주며 일반적인 패턴으로 부터 응용을 하게 되지요.
'프로그래밍 일반 > 객체 지향' 카테고리의 다른 글
| Boost.DI 소개 (0) | 2019.11.10 |
|---|---|
| SOLID 디자인 원칙 (0) | 2019.11.03 |
| Mixin 이란? (0) | 2019.11.03 |
| 이상한 재귀 템플릿 패턴(Curiously Recurring Template Pattern, CRTP) (0) | 2019.10.27 |
| 구상(Concrete) 클래스, 추상(Abstract) 클래스 (1) | 2019.10.27 |