디자인 패턴 후기
지금 까지 디자인 패턴에 대한 공부를 해본 적은 없고 필요에 의해서 사용했던 것이 많이 사용하여서 패턴화 되어 있다는 것까지만 알던 상태였다.
WHY 디자인 패턴?
사실 이유가 간단했습니다. '코드를 더 잘 짜고 싶다.' & 'Java를 사용하면 Java의 장점을 활용하여 객체지향적으로 작성해야 하는데 내가 과연 객체지향 적으로 작성하는 건가?' 이런 생각들을 하다가
디자인 패턴에 관한 스터디를 진행한다고 해서 바로 달려갔습니다.
순탄치 않았던 시작
처음 모임을 가졌는데, 이미 디자인 패턴을 공부했던 분들도 계셨습니다.
그래서 아 내가 여기 있어도 되는건가,, 이런 생각을 했습니다. 나는 처음 하는데 스터디에 도움이 되려나 이런 생각이 있었습니다.
하지만 첫 스터디 회의 때 다들 참여해서 얻어 가고 싶은 것에 얘기했을 때 제가 원하는 방향성과 맞아서 일단 버티자 생각을 했었습니다.
(최대한 빼먹어보자)
사용했던 책
헤드퍼스트의 디자인 패턴이라는 책을 사용한다 했는데, 사실 저는 처음 들었어서 어떤 장점이 있었는지는 잘 몰랐습니다.
이 책의 장점은 한 마디로 전체 맥락을 파악시켜준다. 라고 볼 수 있었습니다.
이야기의 시작
각 챕터마다 고유한 이야기를 가지고 있습니다. 시작과 동시에 패턴과 어울리는 하나의 상황을 설정하며 시작하게 됩니다.
상황을 설명한 후에는 '우리는 이제 이러한 방향으로 구현을 할거야'라는 구현 목표를 제공해 줍니다.
이러한 구현 목표를 잡아줘서 '상황이 달라져도 동일한 구현 목표가 가지고 있으면 구현할 수 있겠다' 라는 생각을 들게 했습니다.
정제하기 전과 후의 코드
public class WeatherData {
public void measurmentsChanged() {
float temp = getTemperature();
float humidity = getHumidity();
float pressure = getPressure();
currentConditionsDisplay.update(temp,humidity,pressure);
statisticsDisplay.update(temp,humidity,pressure);
forecastDisplay.update(temp, humidity, pressure);
}
}상황 설명과 구현 목표에 대한 이해를 기반으로 처음에는 리팩터링 하기 전의 코드를 보여주게 됩니다.
각 코드가 어떤 요구 사항이고, 어떤 역할을 하는지에 대한 추가적인 설명이 있습니다.
이 코드에서 currentConditionsDisplay, statisitcsDisplay, forecastDisplay에서는 구체적인 구현에 맞춰서 코딩했기 때문에 고치지 않으면 다른 디스플레이 항목을 추가하거나 제거 못한다는 등, 현재 코드의 문제점을 알려주고,
'실행 중에 디스플레이를 더하거나 빼려면 어떻게 해야할까요?'와 같이 어떤 방향으로 나아갈지 생각할 수 있도록 우리에게 질문을 던집니다.
5분 드리마
위 정제하기 전의 코드에서 방향을 보여줬다면, 그것을 해결하기 위한 옵저버 패턴이 무엇인지 설명해 줬는데,
이러한 옵저버 패턴을 좀 더 이해하기 쉽게 드라마처럼 대화 형식을 제공해 줍니다.
사실 이 부분은 챕터마다 호불호가 있었습니다. 대화 내용에 '이제 이 바닥에서 내가 아는 회사로는 가기 힘들 거요'와 같이
어떠한 의미도 담겨있지 않다고 생각되는 말들이 좀 많았던 챕터도 있어서 오히려 이해를 방해하는 요소가 되었던 점도 있었습니다.
핵심 정리
이렇게 설명하다 보면 많은 양을 순서대로 다루게 되고, 이 책에서는 디자인 도구상자 안에 들어가야 할 도구들이라는 해당 챕터의 디자인 패턴을 한 페이지로 핵심 정리를 해주기도 했습니다.
코드 퀴즈
마지막에는 패턴에 대해 잘 이해했나를 확인하기 위해 퀴즈를 제공하게 됩니다.
헤드퍼스트 디자인 패턴이라는 책은 위와 같은 특징들이 있다보니, 이해하기는 쉽지만, 단점도 있었던 책이었습니다.
어떻게 해결했을 까?
Design Patterns (refactoring.guru)의 사용 Guru또한 헤드퍼스트와 비슷하게 WHY, HOW가 잘 담겨있지만 더 간략하게 담겨있었습니다.
또한 2가지 더 좋았던 부분이 있었는데 장단점과 다른 패턴과의 관계가 있었습니다.
가장 필수 적으로 사용하는 디자인 패턴들에 대해 설명을 하는데, 실제 상황을 가정하며, 어떤 문제가 있었고, 그 문제를 어떻게 해결해 나가는지를 보여주는 것이 인상 깊고 마음에 들었던 부분입니다.
그렇다 보니, 디자인 패턴 자체를 외웠다기 보단 이해하면서 좀 더 오래 머릿속에 남았다. 라는 느낌을 많이 받았고, 다만 약간의 문제점이 있다면, 장황하다 할 수 있는데 어떤 문제의 경우 어떻게든 문제를 풀어서 설명하려다 보니 이해하기 힘들었던 부분도 있었습니다.
따라서 내가 공부할 때 이해해야만 한다면 이 책을 추천드리고,
하신 다면 이 책과 함께 Design Patterns (refactoring.guru) 를 같이 공부하는 것을 추천드립니다.
왜냐하면, 예제는 많을수록 이해하기 편하다. 헤드퍼스트를 읽으면서 있었던 부족한 설명과 애매모호했던 설명들에 도움을 준다.
스터디 방식
저희는 여러 룰을 정했는데
- 매주 1회 스터디
- 매주 1명의 발표자가 해당 주차의 내용을 요약 및 정리하여 설명하고 토론
- 각 챕터마다 Guru의 예제나 따로 생각한 문제를 코드로 구현하고 Github에 업로드
였습니다. 그리고, 발표 순서는 첫 주에 미리 정했었습니다.
근데 이렇게 하다 보니, 약간의 문제점이 있었는데 내가 발표하는 주차가 아니면, 대충 할까 라는 마음도 살짝 들었지만 다행히 저는 다른 분들에 비해 부족하다는 생각 덕분에 버틸 수 있었습니다.
그래서 다음번에 또 하게 된다면, 이러한 문제를 어떻게 해결할까 생각해 봤는데,
발표자를 스터디 하루 전에 정하고, 그 발표자료를 준비하는 방식으로 해야겠다고 생각했습니다. (우리 팀 스터디에서 이렇게 진행하고 있어서 가져왔습니다ㅎ)
회고
이번 스터디에서 아쉬웠던 부분은, 완성된 코드를 리팩터링 하지 못했던 점입니다. 사실, 팀원 분들과 매주 Guru나 헤드퍼스트에 있는 예시를 직접 구현해 보고 리뷰와 리팩토링을 하자고 약속했었지만,
제 과제를 하기 바뻐 리뷰와 리팩토링은 제대로 하지 못했던 점이 많이 아쉬움이 남았습니다.
하지만 반대로 좋은 점이 많았는데요.
이러한 디자인 패턴을 통해 객체지향적으로 작성하는데 여러 방식을 대안으로 생각할 수 있게 되었던 점이 좋았습니다.
서로 주고받았던 질문들이 가장 기억에 남았던 거 같습니다. 어떤 분이 발표를 하면 다른 사람들이 같이 그거에 대해 토론을 하는 거 자체가 너무 재밌었고, 제가 궁금하다고 생각했던 것들에 대해 거리낌 없이 질문을 드려도 다른 분들이 의견을 무시하지 않고 정성 들여 답변했던 점이 너무 인상 깊었기 때문이고, 이런 팀원들 덕분에 많은 것들 배웠던 스터디였습니다.
헤드퍼스트 디자인패턴은 객체지향을 도와주는 디자인 패턴에 대해 알려주는 역할을 한다 생각합니다. 따라서 항상 이 어떤 패턴을 사용할 수 있다는 보장도 없고 무조건 사용해야 한다는 것은 아니라고 생각하고, 제가 생각하기에는 하나의 의사소통 수단으로 많이 사용하지 않을까 싶습니다.
예를 들어,
어떤 객체를 인터페이스로 빼고, 그 인터페이스를 상속받는 여러 클래스를 만드는데, 각 클래스는 동작기능만 넣어라
와 같이 긴 문장을 전략패턴이라는 하나의 문장으로 변경해서 소통할 수 있다는 장점이 크다고 생각되었습니다.
마지막으로 우리 스터디원 중 한 분이 하셨던 말씀을 마지막으로 마무리하겠습니다. "이런 게 스터디의 순 기능이 아닐까요?"