객체지향의 탄생-디자인패턴과 리팩토링

블로그처럼 네티즌을 위한 훌륭한 도구가 또 하나 있다. 트위터라는 도구이다. 블로그는 '자기 생각과 주장을, 자유롭게 글이나 사진으로 편집해서 올리고, 댓글, 트랙백, RSS, 태그등의 기법으로 쉽게 전파하는 도구' 이다. 트위터는 '블로그 처럼 자기 생각과 주장을, 짧은 글로 올리고, 친구(following, followers) 맺기, RT(친구의 글을 내가 전파함), 댓글등의 기법으로 쉽게 전파하는 도구'라고 정의한다.

 

블로그와 트위터의 정의로부터 이 둘의 공통점과 차이점을 찾아 보았다. 블로그는 편한대로 쓰기도 하지만 대부분은, 글을 쓰기전에 미리 이런식으로 글을 구성하겠다고 생각한다. 블로그는 글쓰기 전에 또는 글을 쓰면서 많은 노력을 요구한다. 트위터는 편한대로 쓴다. 편한대로 쓰면서 친구(follower)들과 교류하면 된다. 트위터는 글을 쓰면서 또는 글쓰기 후에 RT같은 간단한 작업들이 요구된다.

 

블로그는 대부분 어느정도 글의 덩치가 있기 때문에 해당 주제에 대하여 숲에서 나무를 보는 방식으로 작업을 진행한다. 그래서 블로그 글쓰기의 작업 범위는 크다. 트위터는 편하게 쓴 짧은 글로 상대방과 교류하고 다시 의견을 내면서 자신의 생각과 주장을 발전시킨다. 그래서 트위터의 작업 범위는 작다.

 

블로그는 글쓰기 전에 글을 어떻게 전개할지 생각이 요구되기 때문에, 글의 주제에 대해 명확히 이해하고, 대상 독자를 명확히 알아야 한다. 더구나 메타블로그 추천 상위권을 노리는 글이라면 글감 준비부터 쓰는 과정까지 상당한 시간이 필요하기도 하다.

 

트위터는 140자 이내로 편하게 쓰면 되기 때문에, 친구(=follower)들과 어떻게 교류할지 대략 생각만 하면 쉽게 사용할 수 있다. 심지어 '나 이제 자요~' 등의 단순한 일상을 올리더라도 친한 친구(=follower)라면 자신의 글에 반응해줄 것이다.

 

블로그가 자기 생각을 깊이있게 전달한다면, 트위터는 가볍게 그러나 지속적으로 자기 생각을 전달하는 특징이 있다. 블로그는 자신의 내적인 사고력으로 자신의 생각을 전파하는 경향이 있지만, 트위터는 친구(=follower)와의 지속적인 커뮤니케이션으로 자신의 생각을 전파한다. 블로그가 내향적이라면 트위터는 외향적이다.

 

블로그와 트위터는 노력이 필요한 단계도 틀리고, 글의 양도 틀리고, 글재주와 사진찍기 능력과 편집 능력의 난이도도 틀리다. 그러나 결국 자기 생각과 자기 자신을 블르고와 트위터란 도구들을 이용해 널리 알려서, 자신이 원하는 무엇인가를 이룬다는 것에 궁극적인 공통점을 가진다. 블로그와 트위터의 용도와 효과는 비슷하다.

 

 

여기 객체지향 선각자들의 고마운 선물이 또 하나 있다. 리팩토링이라 불리는 기법이다. 디자인패턴은 '특정한 객체지향 개발 영역에서 자주 발생되는 설계 및 구현 문제에 대하여, 유연하고 확장성 높은 객체지향적 설계 패턴으로 해결하는 방법들의 모음' 이라고 정의한적이 있다. 리팩토링은 '기능은 그대로인 상태에서 내부 소스를 유연하고 확장성 높은 객체지향 스러운 코드로 개선하는 작업'이다.

 

디자인패턴과 리팩토링의 정의로부터 이 둘의 공통점과 차이점을 찾아본다. 디자인패턴은 어플리케이션의 설계 단계에서 미리 이런식으로 객체를 구성해야겠다고 결정한다. 디자인패턴은 어플리케이션 개발 전에 투입된다. 리팩토링은 어플리케이션 개발 후 코드를 점검하면서 잘못된 코드가 발견되면 객체지향스러운(=유연하고 확장하기 쉽고 유지보수하기 편한) 코드로 개선한다. 주로 리팩토링은 어플리케이션의 특정 모듈 개발 후에 투입된다.

 

디자인패턴은 설계단계에서 사용되기 때문에 숲에서 나무를 보는 방식으로 작업을 진행한다. 그래서 디자인 패턴을 적용하는 작업의 범위는 크다. 리팩토링은 완성된 코드의 작은 모듈을 개선하는 작업부터 사용되기 때문에 나무에서 숲을 보는 방식으로 작업이 진행된다. 그래서 리팩토링을 적용하는 작업의 범위는 작다.

 

디자인패턴은 어플리케이션 설계단계에서 사용되기 때문에 어플리케이션의 요구사항을 명확히 이해하고, 시스템을 명확히 이해하며, 디자인패턴의 근본 기술인 객체지향 원리에 대해서도 깊게 알아야 한다. 더구나 숲에서 나무를 보는 관점에서 대규모의 작업이 이루어지기 때문에 디자인 패턴은 배우기도 쉽지 않고, 어느 정도 숙달되지 않으면 적용하기 쉽지 않다. 그러나 제대로 적용만 할 수 있다면 한번에 튼튼한 토대를 구출할 수 있다.

 

리팩토링은 작은 코드의 개선단계에서 사용되기 때문에 개선할 코드의 요구사항과 로직만 명확히 이해하며, 코드의 무엇을 개선할것인지 리팩토링 카탈로그만 알면 쉽게 구현할 수 있다. 심지어 객체지향의 근본적인 원리를 이해하지 못하더라도 리팩토링 카탈로그를 따라하면 저절로 잘못된 코드가 바람직한 객체지향 코드로 진화되기도 한다.

 

디자인패턴을 구현하기 위해 미리 깊이 있는 사고가 요구된다면, 리팩토링은 가볍게 그러나 지속적으로 코드 개선이 이루어지는 특징이 있다. 디자인 패턴이 설계자의 깊이있는 한번의 사고로 어플리케이션의 토대를 구축한다면, 리팩토링은 가볍고 활발하게 이미 구축된 토대를 개선한다. 디자인패턴이 정적이라면 리팩토링은 동적이다.

 

디자인패턴과 리팩토링은 쓰이는 단계도 틀리고, 쓰이는 범위도 틀리고, 배움과 적용의 난이도도 틀리다. 그러나 결국 객체지향적으로 어플리케이션을 개발하여 유연하고 확장성 높고 유지보수 편리한 어플리케이션으로 진화하는 목표를 가지고 있다는 것에 궁극적인 공통점을 가진다.

 

디자인패턴과 리팩토링의 적용 효과는 같다.

 

[아키텍트가 소프트웨어 개발 전 단계에서 디자인패턴으로 소프트웨어를 설계한다. 소프트웨어가 완성되었다. 아키텍트나 개발자가 완성된 소프트웨어를 리팩토링한다. ]

 

덧 ) 이 객체지향의 탄생 원고는 제가 책으로 내려다가 일단 잘 안되었는데요. 이유는 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다.등 입니다. 그래도 원고를 일단 블로그에 몽땅 풀어보고 언젠가 제대로 교정해서 다시 도전할 생각입니다. 이점을 감안해서 읽고 객체지향을 이해하는데 도움이 되셨으면 좋겠습니다. 의견도 주셨으면 좋겠습니다. 원고 조금만 교정하면 괜찮을것 같은 출판사 관계자분의 피드백도 환영합니다.