구독중인 블로그를 통해 들어간 써니님의 디자인패턴을 대하는 우리들의 자세를 읽고 많이 공감했다.

무엇보다 디자인패턴이 왜 생겨났는지를 알아야한다.

디자인패턴은 책상머리에서 나온 OO 같은 개념들과는 다르게 실무에서 추출된 개념이다.(Django처럼)

즉 디자인 패턴이란, 특정 문제가 있는 코드를 리팩토링 하는 과정에서
(마틴파울러가 말하는 리팩토링은 '프로그램에 새로운 기능을 넣기위해 작동하는 프로그램의 코드 일부/전체를 개선하는 것'이라고 할 수 있다)
자주 보여지는 몇가지의 일정한 패턴을 묶어서 디자인패턴이라고 정의한 것이다.

이것을 더 정리해보면,
디자인패턴은 원래 작동하는 코드를 정제하는 용도로 쓰이던 방법을 모아둔 것이고,
이는 정의된 문제가 야기될 것으로 예상되는 구조를 가진 설계가 있다면
디자인 패턴을 적용해서 설계하는 것이 낫다는 것이다.(어차피 나중에 기능을 추가하려면 개선해야 하므로)

그런데 요즘은 이것을 거꾸로 생각하는 경향이 있는 것 같다.
학부수업때도 교수님의 수업내용은 대체로
'스트래티지 패턴의 UML은 이렇습니다. 특징은 이러합니다. 스트래티지 패턴을 이용해서 프로그램하나 짜오도록'
이렇게 진행된다.

학생들은 UML만 맞춰서 프로그램을 짜오는데 결국 '테트리스의 블록을 스트래티지 패턴을 이용해서 구현' 하는 지경에 이르게 되는 것이다.
(스트래티지는 상속받은 객체가 동적으로 자신의 행동을 재정의하는 것인데 테트리스 블록이 하는 행동들 중 재정의 되어야 하는 일이 있는가? 모양을 바꾸는 것은 그냥 상속으로도 충분하다.)

어찌되었건 최근 느끼는 점은 전산은 문제와 개선의 연속이라는 점이다.
어떤 새로운 기술이던 문제가 있고 그것을 개선하기 위한 방법이 나오고 그것은 또 다른문제를 안고 있고 또 개선...
기술을 제대로 이해하고 쓰려면 기술이 왜 나왔는지와 어떠한 문제를 안고 있는지를 정확히 이해하고 쓰는 것이 필요하다는 것을 요즈음 깊이 느끼고 있다.