HAMA 블로그

꼬리에 꼬리를 무는 - 유사 디자인 패턴들 (3/4편) 패턴을 공부하거나 할 때 UML 에 집중해서 공부하면 안된다고 생각한다. 구조만을 외우고 구조로 구분을 한 사람은 공부한것을 금방 까먹거나 헤깔려하기 쉽기 때문인데, 이유는 거의 비슷한 구조를 갖춘 패턴들은 정말 많기 때문이다. ( 더 헥깔린것은 동일 패턴이 구조가 다른 경우도 부지기수이다. 의도가 같기 때문. 즉 "의도", "목적" 이 중요하다.) 아래 구조를 보자. 정말 많지 않나?? 이 구조만 보고 뭘 알 수 있을까? 자신이 Composite 패턴만 공부했다면 , 이러한 구조를 보고 무조건 "컴포지트 패턴" 이라고 어디가서 우기지나 않을까 염려된다. 이런 식 또한 많다. 무엇인가?? 당연히 알수가 없다. 또한 저런 동일한 구조에 여러 패턴이 같..

꼬리에 꼬리를 무는 - 유사 디자인 패턴들 (1/2편) 패턴을 공부하거나 할 때 UML 에 집중해서 공부하면 안된다고 생각한다. 구조만을 외우고 구조로 구분을 한 사람은 공부한것을 금방 까먹거나 헤깔려하기 쉽기 때문인데, 이유는 거의 비슷한 구조를 갖춘 패턴들은 정말 많기 때문이다. ( 더 헥깔린것은 동일 패턴이 구조가 다른 경우도 부지기수이다. 의도가 같기 때문. 즉 "의도", "목적" 이 중요하다.) 아래 구조를 보자.정말 많지 않나?? 이 구조만 보고 뭘 알 수 있을까? 자신이 Composite 패턴만 공부했다면 , 이러한 구조를 보고 무조건 "컴포지트 패턴" 이라고 어디가서 우기지나 않을까 염려된다. 이런 식 또한 많다. 무엇인가?? 당연히 알수가 없다. 또한 저런 동일한 구조에 여러 패턴이 같이..

멀티쓰레드 디자인패턴의 꽃이라고 한다면 단연코 "생산자-소비자" 패턴이라고 할 수 있습니다. 그럼 Gof 의 디자인패턴의 꽃은 무엇인가? 라고 묻는다면 DI (Dependency Injection) 와 밀접한 "전략패턴" 이라고 대답하고 싶습니다. 물론 둘다 제 개인적인 생각이죠 :-) 멀티쓰레드/서버코드를 작성할때 거의 무조건 "생산자-소비자" 패턴이 사용되기 마련이며, 다른 고차원 패턴들 (예를들면 node.js 의 기반패턴인 react 패턴) 의 기반이 되면서 동시에 멀티쓰레드 코어패턴을 포함하고 있는 , 즉 "허리" 역할을 제대로 하고 있는 패턴이라고 볼수 있기 때문에 아주 중요하다고 볼 수 있습니다. 자 그럼 생산자-소비자 패턴이 무엇인지 살펴보도록 하죠. 이해하기 쉽게 코드를 쉽게 쉽게 간략히..

제목이 "고찰" 이라니 먼가 있어보이긴한데.. 사실 별거 없습니다. ^^어떤 개발자싸이트에 올라온 질문에 대한 저의 답변을 블로그에 정리해봅니다. 질문: 헤드퍼스트 책 보고 공부하다보니깐, 심플 팩토리보다 팩토리 메서드 패턴이 더 좋다는것같은데,심플팩토리도 충분히 괜찮은것같은데 어떤점이 더 좋은건가요..? 책을 또 읽어봐도 이해가 잘 안되서...답변 부탁드립니다~! 답변: 심플팩토리는 그냥 하나의 부모로부터 상속받은 객체중 하나를 클라이언트에게 던저주는것.팩토리 메소드는 자신이 구현상속을 해야 하며,오버라이딩을 통해 객체 생성하는것! 입니다. 두개의 공통점은 어떤 객체를 생성해서 사용할지를 런타임시까지 미룬다는것이며중요한 차이점은 팩토리가 상속받은거냐, 아니냐일 뿐입니다.따라서 객체생성의 종류의 수 와는..

순서 1. 소개 2. Abstract Factory 패턴 3. State 패턴4. chain of Responsibility 패턴 5. Adapter 패턴6. Bridge 패턴 디자인 패턴을 공부할때 가장 유념해야할 단어는 "의도" 이다. 절대 모양 (구조) 가 아니다. 그리고 구현함에 있어서 책 등에 나와 있는 모양 그대로 구현하려고 할 필요도 없다. 너무 잘 하려고 하다보면 아예 하지도 못할지도 모른다. "의도" 만 확실히 이해한 다음에 구현을 이것저것 거침없이 하다보면.... 코딩에 대한 재미는 생겨날 것이다. 재미는 실력향상을 의미하기도 하고 ~ JDBC 는 자바에서 정한 DB 와의 관계에 대한 행동 지침이다. 행동지침을 공통화하려면 어느 정도의 유사성이 있어야 한다. 세상에는 많은 자동차가 있지..

순서 1. 소개 2. Abstract Factory 패턴 3. State 패턴4. chain of Responsibility 패턴 5. Adapter 패턴6. Bridge 패턴 디자인 패턴을 공부할때 가장 유념해야할 단어는 "의도" 이다. 절대 모양 (구조) 가 아니다. 그리고 구현함에 있어서 책 등에 나와 있는 모양 그대로 구현하려고 할 필요도 없다. 너무 잘 하려고 하다보면 아예 하지도 못할지도 모른다. "의도" 만 확실히 이해한 다음에 구현을 이것저것 거침없이 하다보면.... 코딩에 대한 재미는 생겨날 것이다. 재미는 실력향상을 의미하기도 하고 ~ JDBC 는 자바에서 정한 DB 와의 관계에 대한 행동 지침이다. 행동지침을 공통화하려면 어느 정도의 유사성이 있어야 한다. 세상에는 많은 자동차가 있지..

순서 1. 소개 2. Abstract Factory 패턴 3. State 패턴4. chain of Responsibility 패턴 5. Adapter 패턴6. Bridge 패턴 http://brad2014.tistory.com/344

디자인 패턴을 공부할때 가장 유념해야할 단어는 "의도" 이다. 절대 모양 (구조) 가 아니다. 그리고 구현함에 있어서 책 등에 나와 있는 모양 그대로 구현하려고 할 필요도 없다. 너무 잘 하려고 하다보면 아예 하지도 못할지도 모른다. "의도" 만 확실히 이해한 다음에 구현을 이것저것 거침없이 하다보면.... 코딩에 대한 재미는 생겨날 것이다. 재미는 실력향상을 의미하기도 하고 ~ JDBC 는 자바에서 정한 DB 와의 관계에 대한 행동 지침이다. 행동지침을 공통화하려면 어느 정도의 유사성이 있어야 한다. 세상에는 많은 자동차가 있지만 행동 지침은 비슷하다. 그러기에 운전자들이 다른 메이커의 자동차를 운전하더라도 어느정도는 쉽게 할수있지 않은가.. 마찬가지로 세상에는 많은 DB 가 있고. 각각의 DB 에서 ..

http://brad2014.tistory.com/215 이전 포스팅에서 언급된 Actor 모델 과 ActiveObject 패턴의 차이에 대한 논문이 있다. http://members.unine.ch/anita.sobe/res/RR-I-AS-2014.06.1.pdf 간단 요약 역사 - 멀티코어 프로그래밍의 시대가 왔고 장점에 대한 소개 - 멀티쓰레드 프로그래밍의 어려움 소개 ( 데드락, 레이스 컨디션, 일관성깨짐등) - 그런 환경에서 좀더 안전하고 빠르게 개발하기위하여 Actor 모델같은 동시성 패턴이 생겨나다. - 1973년 에 Actor 모델이 소개되었고, 인공지능의 멀티 에이전트 디자인에 의해 발전되어졌다. - Actor 모델은 그후 Actove Object 패턴같은 다양한 패턴들에 영향을 주었다...

GOF 의 디자인패턴중 하나인 인터프리터 패턴에 대해서 살펴보도록 하자. 인터프리터 패턴은 모든 종류의 GoF 패턴들 중에 가장 어렵다. 물론 인터프리터 자체를 만드는게 어렵 기때문에 덩달아 어렵다는 이야기이고, 모습 자체는 여느 디자인패턴과 비슷하다. 원래 디자인패턴이라는건 사실 모양은 다 비슷비슷하다. 그게 쓰여지는 의도에 따라서 패턴의 구분이 이루어진다. 인터프리터 패턴은 느낌 그대로 어떤 해석기, 즉 "간이언어" 를 만들기 위한 패턴이다. 예를들어 클라이언트-서버 프로그램을 만들때 , 프로토콜로 "사람이 자연스럽게 읽을수 있는 문법형태" 로 하자!! 라고 정할수있는데, 그때 사용하면 되겠다. 프로토콜 예로는 "Select * From Table" 이렇게~ 자 이 글에서는 "program repea..