옛날 블로그

방문자 패턴은, Composite 패턴과 크게 다르지 않다. 내부적으로 예를들어 정말 쉬운 예로, 파일 탐색기를 구현해볼수 있는데 파일 탐색기는 자꾸 여기저기 돌아댕기면서 필요한 파일을 찾아서 자기 호주머니에 그 파일들이 있는지 잘 적어놨다가 방문이 모두 끝나면 사용자에게 결과를 보여줄수 있다. 이 탐색기는 방문자(Visitor)이다. 그리고 이를 받아들이는 놈들은 어떻게 부르는지는 크게 중요하지는 않지만 여기서는 Host로 칭하자. 이 Host들은 방문자의 방문을 받아들이며 accept(Visitor v) 필요한 처리를 해준다. 일단 추상 클래스로 만들어진 Host를 한번 만들어보자. public abstract class Host{ public abstract String getName(); publ..

Chain of responsibility라는 이름에 답이 있다. 각자의 클래스는 어떤 일을 처리할수 있는데, 가끔씩은 내가 처리할수 없는 일도 있다. 이러한 경우 내 선에서 굳이 처리하지 않아도 되고 판단하에 다음 클래스를 태워서 판단하게 할수 있다. 만약, 은행대기열에서 짝수 대기열만 처리하는 은행원도 있으며 홀수만 처리하는 은행원도 있다고 치자. 대기열을 받기는 받는데, 내가 처리하여야 할 상황이 아니면 다른놈으로 넘겨버려야 한다. 이는 마치 회사 상황과도 같는데, 일단 특정 프로세스에 문의사항이 생긴 직원운 지가 찾아볼 생각은 안하고 대충 담당자일것 같은 사람에게 메일을 보내고 바로 처리해주거나 은근히 다른 담당자를 찾아서 포워딩해주기를 바란다. 이제 토스가 일어나는 순간이다. 문의를 받은 직원은..

왜 굳이 메서드를 이용해서 쉽게 쉽게 가지않고, Command라는 인터페이스를 받아서 복잡하게 구성하는가? 클래스로 기능을 설정하면 이력등을 관리하기가 좋고, 나중에 필요한 기능 (ConcreteCommand)를 추가 하기가 쉽다. 단지 Command 만 상속받아서 구현을 하면 되니까. 커맨드 패턴은 기능을 실행하라고 하는 Sender와 요청을 받아들이는 Receiver가 완벽하게 분리되며 요청을 받아들이는 Receiver입장에서는 Sender의 인터페이스 따위는 알 필요가 없는 패턴이다. 위의 UML을 따라서 한번 구현한다. 코드는 시간이 없어서 위키피디아에 있는걸 그대로 따온다. Command 인터페이스는 모든 ConcreteCommand에서 상속을 받아 구현하기때문에 굉장히 간단하게 execute(..

프록시란 참 여러군데서 많이 쓰인다. 인터넷에서는 우회하는데 쓰이기도 하고, 빠르게 내용을 가져올때 쓰기도 한다. 일단 디자인패턴에서 쓰이는 프록시는 빠르게 내용을 가져오고 정말 중요한게 있으면 본 서버에서 데이터를 가져오는 인터넷에서의 프록시와 개념이 같다. 일단, 어떠한 작업이 있다고 하자. 가벼운일과 무거운일. 가벼운일을 처리하는데는 프록시를 쓰고 무거운일을 처리하는데는 본 기능을 부른다. 이렇게 해서 괜히 헤비한 객체의 생성을 피할수 있다. 마치 회사에서의 사원의 모습같다. 온갖 짬처리를 하다가 제대로 큰건이 있으면 보고를 통해서 과장이 처리하게 되는것이다. 위에서 프록시는 지가 처리할수 있으면 처리하며(짬처리) 진짜 본체는 중요한 일만 골라서 하는 놈이다. 이 포스트에서는 단 세개의 직관적인 p..

façade패턴. 정말 별게 아니다 위와같이, 복잡하나 연관성있는 메서드들을 다시 하나로 묶어서 제공하는 지극히 평범한 패턴이다. 이것은 특별한 패턴도 아니며, 그저 기능을 모아놓은 역할만 할 뿐이다. 이 포스팅에서 설명조차 하지 않겠다. 그냥 니가 쓰는 잡다한거 다 모아놓은 클래스로써, 나중에 최종으로 보이는 코드는 꽤나 깔끔하다.

http://hyeonstorage.tistory.com/146 솔직히 위의 글보다 잘 쓰기는 쉽지않다. 아주 잘써놨다. Strategy패턴은 굳이 프로그램적으로 구현할 필요도 없다. 그냥 간단하다. 그냥 공통의 메서드가 있는 인터페이스를 상속받아서 그 클래스에서 구현하는 것이다. 굳이, 메서드를 하나의 클래스에 속하게 하지말고 위처럼 사용하면 된다. 다만, 스칼라에서는 다르다. 구현가능한 trait가 존재하고 있기 때문에 귀찮게 인터페이스를 상속받아 사용하지 말고, trait를 이용해서 여러개를 끼워버리면(mix-in) 된다.

Flyweight 패턴은, 객체를 어마어마하게 많이 생성해야 할때 메모리가 굉장히 많이 들것을 대비하여, 최대한 공유가능한 부분을 이용해 가볍게 부담을 줄여주는 패턴이다. 일단 UML을 한번 엿보고 계속해보자. 출처 http://wiki.western.edu/mcis/ 웹과 같은 화면상에 여러개 구성요소가 존재할수 있는데, 만약 이미지같은것들이 동일하게 반복되고 있다면 별로 바람직하지 않다. 따라서 재사용할건 재사용하고 만들건 만들어서 좀 효용성이 있게 프로그램을 구성하면 좋다! 일단 인터페이스를 하나 만들자. 도형 인터페이스다.public interface Shape { void draw(); } 이를 상속해서 다음과 같은 사각형 클래스를 만들자. 사각형 클래스는 내부에 color와 length 를 가..

Composite 패턴은 마치 나무와 같다. 바로 트리구조라는것. 자꾸 여기저기서 트리구조라고 하기 때문에 더 헷갈리는것 같기도 하다. 그렇지만 뭐 해보겠다. 일단 부품이 있다. Component라고 하자. 그 부품 종류에는 계속 부품을 꽂을 수 있는 Composite, 그리고 더이상 부품을 꽂을 수 없어 끝나는 Leaf 부품이 있다. (트리구조라 보통 이렇게 예를 잡는듯 하다.) 즉, Composite을 이용한다면 계속 부품을 꽂아서 객체를 만들어나갈수 있고, Leaf를 이용한다면 거기는 막다른 부품(?)이다. 일단 다음과 같은 기본 부품을 하나 만들어주자. Componentpublic interface Component { public void operation(); } 이제 이를 상속해서 실제 Le..

InputStream 관련한 자바 클래스를 보고있으면 정신이 아득해진다. 무슨 비슷한 이름들이 이렇게 많은지, 그리고 버전업을 하면서 뭐가 추가되었는지 어디서 코드를 복붙하지 않으면 아예 백지에서 생각해서 어? 그게 무슨 클래스였지 생각하기 힘들다. 출처 : https://www.clear.rice.edu/comp212/02-spring/labs/12/ 뭔가 비슷비슷한 이름들이 보기도 힘든 형태로 붙어있다. 자바 I/O 클래스는 데코레이터 디자인 패턴을 가지고 있는데, 이 데코레이터 패턴은 하나하나 장식을 매다는 클래스를 하나하나 만들어놓았기 때문에 위와같이 복잡한 형태의 UML이 그려질수밖에 없다. 초딩때 크리스마스 트리를 만들던 기억이 난다. 지금이야 귀찮지만, 그때는 얼마나 재미있었는지.. 일단 트..

State 디자인 패턴도 마찬가지이지만 많은 디자인 패턴들은 나중에 변화가 생겼을때 코딩을 최소로 하고 갈아낄수 있게끔 만드는 것이다. 이로인해 추상화레벨은 올라가며 직관성은 조금 떨어지지고 이해하기가 조금 힘들지만, 한번 이해하고 나면 머리굴릴필요가 없다. 중요한것은 갈아낀다는 것에 중점을 맞추면 된다. 만약 State를 쓰지않고 단순한 상태 플래그를 가져가서 if else구문만을 이용해서 프로그램을 작성한다면, 나중에 프로그램이 수정될 경우 기존의 소스코드를 수정해야하기 때문에 어느정도 위험성이 있는것은 사실이다. 만약에 Context를 이용해서 그 대상이 되는 객체만 바꿔준다면, 기존의 소스코드를 수정할 필요 없이 객체만 바꿔주면 된다. 물론 뒷단의 프로그램에 영향이 있는지 없는지는 재확인해야 하는..