[Java Design Pattern] 디자인 패턴이 뭔가요? 왜 필요한가요? 디자인 패턴에 대해 알아봅니다.

반응형

1. Prerequisite

- Java 에 대한 기본 지식.
- 약간의 실무경험. 

2. Intro

이 글을 쓰는 이유가 뭔가요?

저는 현재 프로그래머로서 일하고 있습니다.
사실 전공이 전산은 아니지만, 프로그래밍 하는 것이 재미있어서 이 일을 시작했죠.

새로 회사에 들어와서 일을 하다 보니, 
프로그래밍 언어에 대해 가르쳐주는 입문서들을 읽으면서는 배울 수 없었던
리펙토링이라던지 디자인 패턴 등에 대한 이야기를 많이 접할 수 있었습니다.
사실 프로젝트의 시작과 끝을 혼자서 하고, 프로젝트의 요구사항( Requirement )이 변하지 않는다면.
이 둘은 필요가 없다고 말할 수도 있겠죠..

하지만 프로그래머로써 일해보면 알겠지만, 이건 불가능합니다.

 1. 요구사항은 수시로 바뀌고, 

 2. 함께 코딩하는 경우도 생기며, 

 3. 때에 따라서는 인수인계도 불가피하죠.

이 세가지의 불안한 상황에서 벗어나기 위해서는,

 1. 요구사항 변경에 대한 소스코드 변경을 최소화.

 2. 함께 코딩하는 경우를 고려하여 범용적인 코딩 스타일 적용.

 3. 인수인계 시 인수자가 코드를 빨리 이해할 수 있도록 범용적이며 직관적인 코드 사용.

 
위의 세가지 상황을 타개하기 위한 최선의 방책들을 현재 저는 "리펙토링" 과 "디자인 패턴" 으로 보고 있습니다.
그래서 더욱 효율적인 코딩을 위해서 여기서는 디자인 패턴을 한번 공부해 볼까합니다.

공부만 하면 돼지 이 글을 왜 쓰냐구요?
정리하면서 공부하면 

1. 기억하는데 더 도움이 되고, 

2. 나중에 리뷰 할 때도 편하구, 

3. 마지막으로 읽고 있는 여러분과 정보공유도 되지 않습니까?

그런 이유에서 이 글을 써봅니다.

3. Information.

디자인 패턴이 대체 뭔가요?

각 책의 저자마다, 그리고 각 프로그래머마다 디자인 패턴에 대해 한 마디로 정의하고 싶어하는 것 같습니다.
그래서 그들의 정의를 읽어보면 무슨 말인지 정확히 파악하기가 힘들죠.
물론 이 글을 읽고 있는 여러분이 혹 초보자라면 더욱 그러하겠죠.
이 글은 Tutorial 목적이기 때문에 "이 정도만 알고 있으면 되겠다" 라는 선에서
설명을 해볼까 합니다. 물론 "저도 이 정도밖에" 모르긴 하죠.  X)

디자인 패턴은 많은 실무 프로그래머들이 인정한 효율적인 코딩 방법 또는 구조라고 보면 됩니다.
여기서 말하는 코딩 방법은 타자를 빨리 쳐야 한다, 탭을 눌러 열을 맞춰야 한다 이런게 아니라
어떤 식으로 코딩을 해야

1. 코딩이 명확하고 단순하며,

2. 모듈( class나 function 등 )은 한 가지 기능만 하도록 작게 세분화 시킬 수 있으며

3. 재사용성이 높고

4. 유지 보수가 쉬우며

5. 리소스의 낭비가 없는지 

 
에 대한 "방법론" 을 말하는 것이죠.

이 방법론을 디자인 패턴이라고 부르는 이유를 저는

디자인 패턴 = ( 디자인 = 설계, 구조 ) + ( 패턴 = 많은 프로그래머들이 인정하여 일반적으로 사용 )

이라고 생각합니다. 

이제 어느 정도 개념이 잡히셨습니까?
안 잡혔다면 패턴 하나하나를 먼저 보길 권해드립니다. 계속 이 글만 파시지 말고요.
원래 첫 술에 배부를 순 없잖아요?

그럼 디자인 패턴만 외우면 최고의 프로그래머가 되는 건가요?

그건 아닙니다. 우선 디자인 패턴은 "외우기"만 하는 것이 아니라는 걸 명심해야 합니다. "익히기"를 해야 합니다. 
왜 외우기만 하면 안 되나고요? 
디자인 패턴의 적용은 중, 고등학교 때 수학을 배울 때 선생님들이 하시던 말씀을 잘 생각해보면 됩니다.

"공식을 외운다고 모든 수학 문제를 풀 수 있는 건 아냐!?" 

디자인 패턴은 일종의 수학 공식이라고 보면 쉽죠.
공식을 외운다고 해서 실제 프로그래밍에 100% 적용 가능한 것은 아닙니다.

어느 부분에 이 디자인 패턴을 적용할 것인가에 대한 판단이 있어야 하고,

적용이 가능한 부분이라도 적용했을 때 정말 효율적인가에 대한 판단도 있어야 합니다.

물론 올바르게 적용하는 것도 매우 중요하죠. ( 공식을 충분히 이해해야 올바르게 적용할 수 있겠죠 ) 

"공식 암기와 적용이 항상 최선의 방법은 아니란 것!?"

수학문제와 공식의 관계를 잘 생각하면서 한번 되짚어 보면 이해가 빠르실 것이라 믿습니다.

4. Summary

- 코딩을 하며 다음과 같은 문제에 봉착한다.
 

1. 요구사항이 수시로 바뀐다.
2. 타인과 함께 코딩하는 경우가 생긴다.
3. 때에 따라 인수인계를 받거나 해줄 수 있다.

- 이 같은 상황을 피하기 위해서는 다음과 같은 사항을 지켜야 한다.

1. 요구사항 변경에 대한 소스코드 변경을 최소화
2. 타인과 함게 토딩하는 경우를 고려하여 범용적인 코딩 스타일 적용.
3. 인수인계 시 인수자가 코드를 빨리 이해할 수 있도록 범용적이며 직관적인 코드 사용. 

- 디자인 패턴은 많은 실무 프로그래머들이 인정한 효율적인 코딩방법, 구조, 방법론으로서 다음 요소들을 고려한다.

1. 코딩은 명확하고 단순해야 한다.
2. 모듈( class나 function 등 )은 한 가지 기능만 하도록 적게 세분화 되어야 한다.
3. 재사용성이 높아야 한다.
4. 유지 보수가 쉬워야 한다.
5. 리소스의 낭비가 없어야 한다. 

- 디자인 패턴은 암기가 아니라 익히기 이다.

반응형

저작자표시비영리변경금지

• 카카오스토리
• 트위터
• 페이스북

'프로그래밍 놀이터 > 디자인 패턴, 리펙토링' 카테고리의 다른 글

[Design Pattern/Java] private 생성자를 사용해서 인스턴스 생성을 못하게 하자.  (0)	2012.02.10
[Design Pattern/Java] private 생성자나 enum 타입을 사용해서 싱글톤의 특성을 유지하자.  (0)	2012.02.10
[Design Pattern/Java] 생성자의 매개변수가 많을 때는 빌더(Builder) 를 고려하자.  (1)	2012.02.10
[DesignPattern] Design Pattern에서 성능 향상에 Critical한 Cache Management Pattern에 대해 파헤쳐 봅시다.  (0)	2012.01.23
[Java Design Pattern] 생성자 대신 static factory method를 사용해보자.  (10)	2012.01.10