20150408 디자인 패턴, 잘 적용해 신기한 경험을!!

학원에서 수련할 때, 디자인 패턴이란게 있더란다~ 라고 이야길 들은 기억이 있었다.
어렴풋이 그 때 기억을 더듬어 몇 달전 헤드퍼스트 디자인 패턴을 한 번 읽었다.

많은 디자인 패턴들을 이야기 하고 있고, 완전히 이해하긴 힘들구나... 하고 생각했는데,
이번에 1인 프로젝트를 하면서 몇몇 패턴들을 사용할 기회가 있었다.

물론 완벽히 구현해 내지 못했겠지만,
기억에 남는 두 가지 패턴에 대해 곱씹어 본다.

1. 옵저버 패턴
  옵저버 패턴의 경우 HF(헤드 퍼스트)에서는 기상 관측소에서 데이터 변화가 있을 때 마다
데이터 변화가 궁금한 옵저버들에게 데이터변화를 알려준다(수치도 함께).
이때 관측소는 주제(subject)가 된다.

나도 마찬가지로 옵저버 패턴을 구현하려 했는데,
사실 데이터의 변화에 따른 데이터 값 갱신을 목표로 하는 프로젝트가 아니어서
조금 애매하게 구현을 했다.
옵저버 패턴에는 객체가 데이터를 보내주능 방법과 옵저버가 데이터를 가져가는 방법
두 가지가 있는데, 나는 보내주는 방법을 사용한 것 같다...?!

그리고 양쪽에서 서로 객체가 될 수 있는 상황이 발생했기 때문에
그리고 옵저버도 자동으로 등록하고 싶어 일종의 전략(Strategy) 패턴도 구사 해 봤으나
뭐 그럭저럭 구사된 듯 하다.

사람들이 이야기 하길(혹은 책에서) 디자인 패턴은 수 많은 사람들의 고민의 공통적인
부분을 일반화해서 해결하려 했기 때문에 내 상황에 맞춰 구현하기도 까다로우며
이해하기 또한 쉽지는 않다고 카더라...
그래서 최초의 목표는 이런게 있구나 하고 알고, 대충 이해하고 넘어가는 것이었고
나쁘지 않은 생각 같았다.

2. 싱글톤 패턴
  학원에서 선생님의 말을 기억해 더듬어(*-_-*) 보면 일종의 셋팅 객체(?)
즉, 상태를 저장하는 변수가 여기저기 난립해 있다면 항상 같은 상태를 보여줄 수 없기
때문에 이러한 상태를 저장하는 객체는 프로그램상에 하나만 있어야 한다! 라고
말씀해 주신것 같다. 라고 생각한다.

이번에 싱글톤을 구현하면서 멍충이처럼 잘못 구현해서
이 객체를 호출할 때 마다 매번 데이터를 읽어오는 불상사가 발생했다.
원래의 의도는 싱글톤 객체가 생성될 때, 데이터를 가지고 있고 나는 그 데이터를
읽어서 불러오는게 아니라 그냥 부르기만 하면 되도록(무슨 소리지?) 구현하고 싶었다.

결과적으로 객체를 호출할 때 마다 부르는 잘못된 경우에는
프로그램 실행 시 '이게 언제 다 불러와서 화면에 보여주려나...' 라는 생각을 해야 했다면
싱글톤을 제대로 구현한 경우는 '이게...' 라고 생각한 순간 화면에 출력된 경험을 할 수
있었다.

구체적인 시간을 측정하지는 않았지만, 이 글을 쓰면서 게을러지기 싫어
직접 측정한 뒤 시간을 쓴 후 글을 마무리 지어야겠다.

System.currentTimeMillis();를 이용해 측정
이상한 싱글톤(3494)
싱글톤(402)

이정도면 뭐... ㅎㅎ 신기한 경험!


암튼...

난 논리적이지도, 똑똑하지도 않기 때문에 앞으로도 삽질을 많이 하겠지만...
원숭이처럼 까먹지 않고 기억을 계속 해 낸다면 좋겠다.