디자인 패턴을 잘 기억하는 한 방법

Posted on

흔히 이공계통은 외어서 한다고 하기도 합니다. 이 말들이 옳은 부분도 있겠지만 대부분의 경우 이런 조건에 빠지지 않게 잘 받아들이십니다. 제가 이 말을 하는 이유는 이러한 이해가 갖는 추천되는 마인드가 아니면, 공부하는 방법을 저해하기도 해서네요. 대부분의 기술자분들은 긍정적인 마인드로 업무에 임하셔야 해서 한 문제에 대해 심도있게 사유하시니 공부법에 대한 다른 이해를 잘 안하십니다. 보통은 문제가 없는데, 초심자분들은 때로는 생각치못한 문제가 있기도 하네요. 세상의 모든 것은 이해의 문제이고, 추론적이라 서로 다른 판단끼리 이어져있습니다. 언어적으로는 외관으로 보면 구별되는데, 실재로는 한 분야에서 생각한 것이 다른 분야에도 이어지는 것이네요. 이는 공부 방법이나 실천의 차이로도 이어집니다. 생각보다, 비전공이신 분들이 IT 기술을 보면 장벽에 부딪히는 것도 이런 추론적인 것에 대한 부담감에서 유래하기도 하죠. 하다가 안되거나, 질문에 대한 어려움이 있으면 이공계통은 외어서한다고 하기도 하죠. 이런 이해가 워드프레스 수익창출에 참여하시는 분들도 느낍니다. 테마를 만들고, 누구나 수익창출이 된다고 하는 전문가의 말에 관심이 있게 되어 하다가도 안되면 자신감이 사라집니다.

이 경우를 IT를 배우고 싶은 초심자분들께 확장하면요. 하나의 노하우를 알면 나머지 부분은 잘 이어가지기도 할 것입니다. 이공계통은 외우는 것을 잘 해야 하기도 하지만, 요령을 알고 차근차근 배우면 교육 기회가 심하게 박탈된 경우가 아니라면 잘 할 수 있는 요령이 있습니다.

수학도 보면 수식이 첫대면시 일으키는 갑갑함에 의해 어렵다고 느끼지만 임해서 해보면 생각보다 안어려운 경우가 많죠. 합산을 표시하는 시그마 기호가 그러한데요. 1부터 10까지 더하는 간단한 수식인데도 시그마 기호로 되어 있으면 이 기호의 생소함에 의해 갑갑함이 느껴져서 시작조차 막힙니다.

우선 IT에서 중요하게 보는 소스코드에 대해서도 이런 부담을 느낄때마다 나도 할 수 있다고 느끼고 이어가는 실천력이 중요합니다. 위에 워드프레스 수익창출로 뛰어든 분들도 동기부여가 강하게 되어있다는데서 방법을 찾으면 됩니다. 보통 책을 추천하는데, 누구에게나 딱 맞춤인 책을 찾기는 어렵죠.

소스코드 이해를 예로 들면요.

와 같은 코드를 보면 일상적인 언어와 다르기에 보자마자 겁이 들기도 합니다. 그러나 위와 같은 시그마 기호를 배우고 딱 보고 너무 어렵게 생각하지 않는 것과 같은 마인드로 임하면 결국에는 이해가 됩니다.

중요한 핵심은 1부터 100까지 더하는 코드라는 것이구요. 반복작업을 위해 루프를 돌린다는 것부터 생각하면 쉽습니다. 중요한 핵심은 for 루프로 1부터 100까지 더하는 구문을 작성한 것입니다. for 루프든 어떤 코드든 구문으로 이루어져 있고 구문은 특정 기능이 구현된 문장들이 모인 코드의 형태입니다. 구문은 하나의 또는 여러개의 각 문장별로 담당하는 기능을 모아서 최종적인 기능을 수행하게 합니다. for 루프 문을 예로 들었는데, 고유의 문법 형태가 키워드마다 달라서 이를 준수하면서 코드를 작성합니다.

for () 안에 들어간 ;로 구분된 부분을 각개격파로 보세요.

int c = 0;은 c를 0으로 초기화한다는 의미입니다.
for 루프 안의 괄호에서 int i = 1은 루프를 돌리는 초기조건을 i = 1로 설정하라는 의미입니다.
i <= 100은 1에서 100까지 i가 도달하는 동안 for 루프를 실행하라는 의미구요
i++는 i <= 100일 동안 1씩 i를 증가시킨다는 것입니다.
for 루프의 블락 안에 c = i + c; 는 i 증가분을 c와 합해서 c에 더하라는 의미죠.

이 순차적인 인식이 되면 구문에 대한 이해가 된 것입니다. { } 블락 안에 들어간 코드가 100번 실행된다고 보면 됩니다.

보통 변수 선언, 초기화 등의 코드는 쉬운데 코드가 기호적으로 일상적인 언어와 다르고 순차적인 사고가 필요할때 어려움을 느끼지만, 임해서 해보면 체현이 되게 되어 있습니다. 남들도 하는데 못하겠어요?

위의 코드에서 중요한 것은 패턴입니다. 사람마다 조금씩 다르게 짜도 기본은 같은 패턴입니다. 패턴이 달라져도 차이를 감지할 수 있다면 첫단계를 잘 한 것이고 각각의 흐름별로 바뀐 부분이 어떤 실행을 하게 할지 예측하면 좋습니다. 왠만하면 다 하죠.

와 같은 차이가 주어졌을때, 이보다 위에 소개한 코드에서 얻어진 이해를 바탕으로 임하면 되는 것입니다.

1부터 100까지 더하라는 문제를 받았다면,

숫자를 담는 변수를 몇개나 어떤 타입으로 만들지
루프를 돌릴지 그냥 수동으로 더할지

를 생각해보면 좋습니다. 무엇보다도 패턴을 볼 수 있도록 해서 주어진 문제에 대해 코드 구문을 이렇게 저렇게 바꾸는 구상의 순발력이 중요하네요. 순발력은 이미 풀어진 코드를 떠올려보는 순발력이구요. 첫대면했거나, 공부하는 과정에서는 구상이 느려도 큰 문제는 없습니다. 자기것으로 만드는 노하우가 중요합니다. 초심자분만 느린게 아니라 첫대면하면 누구나 판단을 신중하게 할 수밖에 없죠.

디자인 패턴 또한 같습니다. 소프트웨어 공학이라고 거창한 단어로 된 분야에서 연구하는 주제라, 가슴이 턱 막히는 것이 아니니 요령을 알아내서 적용하면 좋습니다.

디자인 패턴에서 중요한 핵심은

(1) 소스코드를 만들때 누구나 경험하는 문제를 어떻게 효율적으로 해결하느냐
(2) 누구나 경험하는 문제를 이미 알고 있는지의 여부에 의한 경험적인 시도 경험
(3) 이를 일반화한 코드를 보고 패턴으로 집어내서 만들기
(4) 소스코드들이 서로를 참조하는 구조를 알기

이 네가지인데요.

(1)은 누구나 프로그램을 만들다보면 규칙에 따라 프로그램을 만드는데, 아무런 사전 판단없이 기본적인 문법만 가지고 만들다보면 코드가 방만해지고 읽기가 어려워지고 로직들이 서로 얽혀서 유지보수가 어려워지는 것이 일반이라, 기업 단위의 프로젝트 진행시 이러한 문제들을 어떻게 해결해야 하는지를 연구한 결과물이 디자인 패턴이라는 것이구요.
(2)는 (1)에서 말한 것이 누구나 알 수는 있어도 실재 프로그램을 만들어본 경험없이 임하면 피부로 와닿지 않아서 체현이 안되게 되니, 디자인 패턴을 배우기전에 여러 프로그램을 만들어보는 시도를 하라는 것입니다.
(3)은 디자인 패턴도 소스코드의 한 형태라, 각각의 디자인 패턴에 형태를 잘 보고 기억해서 이후에 자기 프로젝트에 적용할만큼 패턴 인식을 해두라는 것인데요. (1)과 (2)를 잘 해두었다면 실천이 되는 부분입니다.
(4)는 디자인 패턴 각각이 이루어져 있는 전체적 관점에서, 한 클래스가 어떤 클래스와 어떤 관계로 연관이 맺어져 있는지를 알 수가 있게 하라는 것입니다. 보통 클래스 다이어그램으로 표현하는데, 클래스 다이어그램을 보고 소스코드에 들어가는 구문이 어떻게 될지를 예측해보면 됩니다. 위에 소개한 구문의 패턴과, (1), (2), (3)이 도움이 될 것입니다.

특히 설명들에서 일반화된 핵심 의미를 추출해낸다면 좋습니다.

유지보수의 관점에서 왜 new 연산자로 직접 결합하는 것을 피하는가, getter와 setter를 쓰는 이유는 무엇이고 생성자로 객체를 넘기는 이유는 무엇인가
그냥 두개의 소스코드로 구현하지 않고 여러개로 일일히 나누어 코드를 배치해서 관련을 맺는가
인터페이스를 두는 이유는 무엇이고 인터페이스를 분리해내서 구조에 포함시키면 어떤 이점이 있는가

이 세가지가 우선 기본이라고 보구요.

소스코드를 구성하는 클래스에서 책임과 관점을 분리한다는 것은 무엇인가
의존성을 주입한다는 것은 무엇인가
유지보수가 간편해진다는 것은 무엇인가

이 세가지도 잘 살펴보면 확장되는 소프트웨어 개발도 잘 이해가 될 것입니다.

많은 경우 해설이 충분치 않더라도 예시된 소스코드들이 서로 다른 해설에서 공통되게 나온다면 뼈대를 외우는 것도 좋습니다.

와 같은 이일민님께서 예시하신 코드에서 ConnectionMaker 인터페이스 클래스와 이를 사용하도록 한 UserDao 클래스의 구조가 왜 그런지를 이해하는 것과 같은 이해의 노하우입니다. 이 경우에 중요한 것은 new 연산자를 최소한도로 쓰면서 변경을 최소화하게 만들고 왜

이렇게 변경을 가하는지, 차이가 무엇인지 알면 됩니다. 즉 new 연산을 어느 코드에 둘 것인지, new 연산을 최소화하기 위해 getter와 setter, 생성자를 통해서 connectionMaker 객체를 넘기면 얻어지는 이점은 무엇인지를 알면 이해가 자연스럽게 풀립니다.

다시 말하면 소스코드에 나오는 구문이나 클래스 다이어그램의 기호적인 것에 압도되지 않고 임해서 상세를 알려고 하면 된다는 것이죠.

이것은 직관적으로 설명하는 책으로는 이일민님의 토비의 스프링 3.1과 조영호님의 객체지향 관련 설계책 두 종이 좋네요.

두 분의 해설에서 공통점은 우선 기존에 최소한도의 문법으로 작성하던 코드가 문제가 일으켜지는 이유 설명을 하시고나서 이를 개선하는 방법론적인 해결법을 소개해주신다는 것입니다. 여기서도 패턴을 인식하고 서로 다르게 보이는 코드와 해설 방식에서 참고점을 찾는 것이 되면 잘하시는 것입니다.

핵심 개념을 말씀드리면요.

코드의 재사용
관심의 분리
책임의 분리
클래스끼리의 결합도
객체를 넘기기
인터페이스의 역할
변경을 허용하는 경우와 아닌 경우
의존성 주입
제어의 역전

이런 개념들을 이해하고 서로 다른 해설들에서 찾아보는 것을 할 줄 안다면 되는 것입니다.

특별히 이일민님 책과 조영호님 책을 추천합니다. 아주 잘 설명해주셔서 좋네요.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다