pupustory@

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이터레이터 패턴(Iterator Pattern)

무궁화호 열차를 타면 열차 티켓을 확인하고 펀치로 찍는 승무원을 본 적이 있을 것이다. 무궁화호는 승무원이 있고, 발급된 티켓이 있다. 열차가 출발하면 승무원은 열차의 티켓을 확인한다. 이때 순서는 순차적(좌석번호 순)으로 접근하며 정보를 확인 한다.

무궁화호 열차 [MugungTrain.java]package pupustory.designpatterns.iterator; public class MugungTrain { Ticket[] ticket; // 티켓 MugungTrainman trainman; // 승무원 // 생성자로 티켓(탑승자), 승무원을 받습니다. public MugungTrain(Ticket[] ticket,MugungTrainman trainman) { this.ticket = ticket; this.trainman = trainman; } // 열차가 출발 합니다. public void goTrain() { System.out.println("열차가 출발 합니다~"); setTicket(); // 출발시 티켓 확인 } public void setTicket() { System.out.println("승무원 티켓 확인 시작!"); // 승무원에게 티켓을 넘겨줍니다. trainman.setTicket(ticket); } }

무궁화호 승무원 [MugungTrainman.java]package pupustory.designpatterns.iterator; public class MugungTrainman { // 승무원이 확인할 티켓 Ticket[] ticket; // 넘겨받은 티켓을 설정 합니다. public void setTicket(Ticket[] ticket) { this.ticket = ticket; // 티켓 확인 checkTicket(); } // 0번 좌석부터 티켓 수만큼 순차적으로 접근 합니다. public void checkTicket() { for (int i=0; i<ticket.length;i++) { System.out.println(ticket[i].toString()); } } }

티켓 [Ticket.java]package pupustory.designpatterns.iterator; public class Ticket { private String origin; private String dest; private int seat; private boolean boarding; public String getOrigin() { return origin; } public void setOrigin(String origin) { this.origin = origin; } public String getDest() { return dest; } public void setDest(String dest) { this.dest = dest; } public int getSeat() { return seat; } public void setSeat(int seat) { this.seat = seat; } public boolean isBoarding() { return boarding; } public void setBoarding(boolean boarding) { this.boarding = boarding; } public String toString() { return "[좌석번호:"+seat+"]" +"\t[출발지:"+origin+"]" +"\t[목적지:"+dest+"]" +"\t[승차여부:"+boarding+"]"; } }

실행 프로그램 [StartApp.java]package pupustory.designpatterns.iterator; public class StartApp { public static void main(String[] args) { // 탑승자 수 final int MAX = 10; // 탑승여부 (무작위) java.util.Random random = new java.util.Random(); // 탑승자 수 만큼 티켓을 발급 합니다. Ticket ticket[] = new Ticket[MAX]; // 티켓 발급 for (int i=0; i<MAX;i++){ ticket[i] = new Ticket(); ticket[i].setOrigin("서울"); ticket[i].setDest("부산"); ticket[i].setSeat(i); ticket[i].setBoarding(random.nextBoolean()); } //승무원 생성. MugungTrainman trainman = new MugungTrainman(); // 열차 생성.탑승자(티켓)와 승무원을 넘깁니다. MugungTrain train = new MugungTrain(ticket,trainman); // 열차가 출발 합니다. train.goTrain(); } }

지금까지 무궁화 호 열차는 아무 문제 없이 운행해 왔다. 그런데 이번에 새마을 호 열차 티켓 확인은 다른 방식으로 접근하게 되었다. 기존에 사용하던 티켓 배열 대신 java.util.List 인터페이스를 이용하는 컬렉션을 사용하기로 한 것이다. 해서 접근에 대한 문제점이 발견 되었다. 어떤 열차(비록 종류는 다르지만..)는 배열을 통해 티켓을 확인하고 어떤 열차는 컬렉션을 통해 확인하는 것의 문제점을 해결해야 한다.

사실 이부분은 어뎁터 패턴을 이용해도 된다. 예를들어 java.util.List의 경우 다음과 같은 코드가 작성 될 것이다.

java.util.List list = new java.util.ArrayList(); for (int i=0,count=list.size();i<count;i++) { (Ticket)list.get(i); }

이런식으로 원소에 접근하는 것 이다. 쉽게보면 이것은 이전에 살펴본 어뎁터 패턴을 통해서도 쉽게 사용 가능해 보인다. 하지만 이번엔 이터레이터 패턴을 이용해 적용 할 것이다. 이유는 이터레이터와 어뎁터는 '목적'이 전혀 다른 패턴이기 때문이다. 어뎁터는 서로 다른 클레스의 인터페이스를 호환시키는데 목적이 있고, 이터레이터는 '동일한 방법으로 순차적인 원소에 접근'하는데 목적이 있다.

열차의 티켓 확인은 순차적으로 모든 원소에 접근한다. 따라서 이터레이터가 목적에 더 맞을 것이다. 친절하게도 자바의 기본 패키지로 이터레이터 인터페이스를 제공해 준다. 어차피 오픈소스인 자바는 속 내용을 쉽게 알 수 있다. java.util.Iterator내용은 다음과 같다.

package java.util; public interface Iterator<E> { boolean hasNext(); E next(); void remove(); }

딱 3가지만 구현하면 된다.(JDK 5.0 기준이고, 1.4는 제너릭이 없을 것이다.) hasNext()는 다음원소가 있는지 여부를 확인(반복조건)하고 next()는 현재위치의 원소를 돌려주고 위치를 증가시키고, remove()는 현재 원소를 삭제 한다. remove()는 사용하지 않을것 이므로(열차 운행중 내쫓을수 없으니 ..)UnsupportedOperationException을 사용할 것 이다.

개선된 무궁화호 [MugungTrain.java]package pupustory.designpatterns.iterator; public class MugungTrain{ Ticket[] ticket; // 티켓 MugungTrainman trainman; // 승무원 // 생성자로 티켓(탑승자), 승무원을 받습니다. public MugungTrain(Ticket[] ticket,MugungTrainman trainman) { this.ticket = ticket; this.trainman = trainman; } // 열차가 출발 합니다. public void goTrain() { System.out.println("열차가 출발 합니다~"); setTicket(); // 출발시 티켓 확인 } public void setTicket() { System.out.println("승무원 티켓 확인 시작!"); // 승무원에게 티켓을 넘겨줍니다. // 이번엔 Iterator을 생성해 넘겨 줍니다. trainman.setTicket(new IteratorMugung(this)); } public Ticket[] getTicket() { return ticket; } }

개선된 승무원 [MugungTrainman.java]package pupustory.designpatterns.iterator; public class MugungTrainman { // 승무원이 확인할 티켓 Ticket[] ticket; java.util.Iterator<Ticket> iter; public void setTicket(java.util.Iterator<Ticket> iter) { // Iterator를 받고 확인 합니다. this.iter = iter; // 티켓 확인 checkTicket(); } // 0번 좌석부터 티켓 수만큼 순차적으로 접근 합니다. public void checkTicket() { // Iterator를 통해 다음원소가 있는지 확인 후 실행 합니다. while(iter.hasNext()) { Ticket checkTicket = iter.next(); System.out.println(checkTicket.toString()); } } }

새로 작성한 Iterator [IteratorMugung.java]package pupustory.designpatterns.iterator; public class IteratorMugung implements java.util.Iterator<Ticket>{ private int index = 0; private Ticket[] ticket; public IteratorMugung(MugungTrain train) { this.ticket = train.getTicket(); System.out.println(ticket.hashCode()+" iterator"); } public boolean hasNext() { if (index < ticket.length) { return true; } return false; } public Ticket next() { return ticket[index++]; } public void remove() { throw new UnsupportedOperationException("지원하지 않음"); } }

티켓(변화없음) [Ticket.java]package pupustory.designpatterns.iterator; public class Ticket { private String origin; private String dest; private int seat; private boolean boarding; public String getOrigin() { return origin; } public void setOrigin(String origin) { this.origin = origin; } public String getDest() { return dest; } public void setDest(String dest) { this.dest = dest; } public int getSeat() { return seat; } public void setSeat(int seat) { this.seat = seat; } public boolean isBoarding() { return boarding; } public void setBoarding(boolean boarding) { this.boarding = boarding; } public String toString() { return "[좌석번호:"+seat+"]" +"\t[출발지:"+origin+"]" +"\t[목적지:"+dest+"]" +"\t[승차여부:"+boarding+"]"; } }

실행 프로그램 [StartApp.java]package pupustory.designpatterns.iterator; public class StartApp { public static void main(String[] args) { // 탑승자 수 final int MAX = 10; // 탑승여부 (무작위) java.util.Random random = new java.util.Random(); // 탑승자 수 만큼 티켓을 발급 합니다. Ticket ticket[] = new Ticket[MAX]; // 티켓 발급 for (int i=0; i<MAX;i++){ ticket[i] = new Ticket(); ticket[i].setOrigin("서울"); ticket[i].setDest("부산"); ticket[i].setSeat(i); ticket[i].setBoarding(random.nextBoolean()); } //승무원 생성. MugungTrainman trainman = new MugungTrainman(); // 열차 생성.탑승자(티켓)와 승무원을 넘깁니다. MugungTrain train = new MugungTrain(ticket,trainman); // 열차가 출발 합니다. train.goTrain(); } }

java.util.Iterator를 상속받아 새로운 클래스를 만들었다. 그리고 승무원이 티켓을 확인할때 티켓을 넘겨주는 것이 아니라 작성한 Iterator를 넘겨 줬다. 이제 승무원은 Iterator를 통해 접근하면 될 것이다. remove()는 구현하지 않아서 throw했다.

이로써 얻는 이점은 동일안 인터페이스를 제공함으로써 지금까지의 방식과 앞으로 추가될 방식이 통합되는 점이 될 수 있다.

Pupustory Dev/Design Patterns

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

템플릿 메소드 패턴(Template Method Pattern)

PC방 (주)PUPUSTORY에서는 좀 더 나은 고객 서비스를 위해 게임의 종류에 따라 최적화된 PC를 제공하고 있으며, 이를 관리(엄밀히 따지면 재설치)하기 위해 프로그램을 제작 하였다. 처음 작성한 프로그램의 코드는 다음과 같다.

서브 pc클래스 (PointPC_01.java)package pupustory.designpatterns.templatemethod; public class PointPC_01 { // os install public void installOS() { System.out.println(" : PC INSTALL OS !"); } // pc format public void formatPC() { System.out.println(" : PC FORMAT !"); } // 이 pc에는 스타크래프트를 설치합니다. public void installProgram() { System.out.println("install : Starcraft"); } }

서브 pc클래스 (PointPC_02.java)package pupustory.designpatterns.templatemethod; public class PointPC_02 { // os install public void installOS() { System.out.println(" : PC INSTALL OS !"); } // pc format public void formatPC() { System.out.println(" : PC FORMAT !"); } // 이 pc에서는 와우를 설치합니다. public void installProgram() { System.out.println("install : World of warcraft"); } }

실행 프로그램(StartApp.java)package pupustory.designpatterns.templatemethod; public class StartApp { public static void main(String args[]) { // 1번pc생성 PointPC_01 pc_01 = new PointPC_01(); // 2번pc생성 PointPC_02 pc_02 = new PointPC_02(); // 1번pc 포멧 pc_01.formatPC(); // 2번pc 포멧 pc_02.formatPC(); // 1번pc os인스톨 pc_01.installOS(); // 2번pc os인스톨 pc_02.installOS(); // 1번pc 프로그램 설치 pc_01.installProgram(); // 2번pc 프로그램 설치 pc_02.installProgram(); } }

문제점은 바로 ‘공통되는 부분’이 많다는 점과 ‘할때마다 불필요 하게 구현하는 부분’이다. 모두 개별적이므로 하나의 코드를 수정할때 모든 코드를 일일이 수정해야 하며, 중복되는 코드도 많고, 새로운 게임이 출시하여 PC에 설치할때 프로그램의 배포시 새로 작성해야 하므로 여간 귀찮은 일이 아니다.

템플릿 메소드 패턴은 큰 의미로 ‘공통은 상위에서 구현하고, 서브클래스에선 구미에 맞게 알아서 구현(이를테면 추상화 된 메소드)한다.’라고 간단히 말할 수 있다. 여기서 좀 더 세밀하게 살펴보면 ‘공통은 상위에서 구현한다. 단, 많은 부분이 겹치고 몇몇의 서브클래스에서 변경사항이 있다면, 오버라이딩해서 사용한다.’고 할 수 있다. 이것은 템플릿 메소드 패턴이 간단하게 하나의 패턴 방식만 뜻하는 것이 아니라 ‘하나의 템플릿에 서브클레스가 템플릿을 그대로 사용할수도, 그것을 바꿀수도’있다는 큰 범위의 의미이다. 먼저 강제성(?)을 띄고 있는 추상화를 통해 구현해 보자.

템플릿 클래스 (PCInstaller.java)package pupustory.designpatterns.templatemethod; public abstract class PCInstaller { // os install final public void installOS() { System.out.println(" : PC INSTALL OS !"); } // pc format final public void formatPC() { System.out.println(" : PC FORMAT !"); } // 서브에서 구현할 설치 프로그램. abstract public void installProgram(); }

서브 pc클래스 (PointPC_01.java)package pupustory.designpatterns.templatemethod; public class PointPC_01 extends PCInstaller { // 이 pc에는 스타크래프트를 설치합니다. public void installProgram() { System.out.println("install : Starcraft"); } }

서브 pc클래스 (PointPC_02.java)package pupustory.designpatterns.templatemethod; public class PointPC_02 extends PCInstaller { // 이 pc는 와우를 설치합니다. public void installProgram() { System.out.println("install : World of warcraft"); } }

실행 프로그램 (StartApp.java)package pupustory.designpatterns.templatemethod; public class StartApp { public static void main(String args[]) { // 1번pc생성 PCInstaller pc_01 = new PointPC_01(); // 2번pc생성 PCInstaller pc_02 = new PointPC_02(); // 1번pc 포멧 pc_01.formatPC(); // 2번pc 포멧 pc_02.formatPC(); // 1번pc os인스톨 pc_01.installOS(); // 2번pc os인스톨 pc_02.installOS(); pc_01.installProgram(); pc_02.installProgram(); } }

이 부분에서 접근자를 final로 적용한 메소드는 하위에서 오버라이딩 할 수 없으며, 특정 추상화된 메소드는 서브에서 반드시 구현해야 한다. 하지만 구현해야 할 내용이 많다면? 상위에서 해두는것이 더 수훨할 것이다. 만약 그부분이 ‘다른 서브 클래스’에서 바꿔야 한다면? 쉽게 오버라이딩을 이용하면 된다. 코드를 보자.

템플릿 클래스 (PCInstaller.java)package pupustory.designpatterns.templatemethod; public abstract class PCInstaller { // os install public void installOS() { System.out.println(" : PC INSTALL OS !"); } // pc format public void formatPC() { System.out.println(" : PC FORMAT !"); } // 서브에서 구현할 설치 프로그램. abstract public void installProgram(); // 메신저를 설치합니다!기본적으로 MSN이 설치되는군요? public void installMessenger() { System.out.println(" : PC INSTALL MSN Messenger"); } // 이건 후크(hook)입니다. 설명을 참조하세요! public void installOther() {} }

서브 pc클래스 (PointPC_01.java)package pupustory.designpatterns.templatemethod; public class PointPC_01 extends PCInstaller { // 이 pc에는 스타크래프트를 설치합니다. public void installProgram() { System.out.println("install : Starcraft"); } }

서브 pc클래스 (PointPC_02.java)package pupustory.designpatterns.templatemethod; public class PointPC_02 extends PCInstaller { // 이 pc는 와우를 설치합니다. public void installProgram() { System.out.println("install : World of warcraft"); } // 2번pc는 msn대신 네이트온으로 대체했네요. public void installMessenger() { System.out.println(" : 네이트온설치할꺼야 !"); } public void installOther() { System.out.println("멋진 XX를 보기위해 KMP를..>_<"); } }

실행 프로그램 (StartApp.java)package pupustory.designpatterns.templatemethod; public class StartApp { public static void main(String args[]) { // 1번pc생성 PCInstaller pc_01 = new PointPC_01(); // 2번pc생성 PCInstaller pc_02 = new PointPC_02(); // 1번pc 포멧 pc_01.formatPC(); // 2번pc 포멧 pc_02.formatPC(); // 1번pc os인스톨 pc_01.installOS(); // 2번pc os인스톨 pc_02.installOS(); // 1번pc 프로그램 설치 pc_01.installProgram(); // 2번pc 프로그램 설치 pc_02.installProgram(); // 1번pc 메신저 설치 pc_01.installMessenger(); // 2번pc 메신저 설치 pc_02.installMessenger(); // 1번pc 기타 프로그램 설치. 과연 있을까요? pc_01.installOther(); // 2번pc 기타 프로그램 설치. 과연 있을까요? pc_02.installOther(); } }

일부는 추상화된 메소드를 사용하지 않았으므로 그냥 상위 클래스의 내용을 쓸 수도있고, 경우에 따라 오버라이딩(installOther())을 통해 재정의 할 수도 있다. 접근자가 final이라면 오버라이딩 할 수 없겠지만 여기선 public로 선언되어 있다. 하지만 상위 클레스에선 하는일이 없다. 그냥 {}만 있을 뿐이다. 이렇게 하는일이 없고(혹은 조건없이 같은값을 반환 한다던지 .. 즉 어떤 분기나 로직이 없는..), 재정의 가능한 메소드를 '후크(hook)’라 한다. 후크를 구현해 알고리즘에 추가 수행할 수도 있고, 이것을 내버려 두면 아무일도 하지 않을 것이다.

Pupustory Dev/Design Patterns

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[head first design patterns]내용을 일부 인용 했습니다.

퍼사드 패턴(Facade Pattern)

어떤 서브시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공. 퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브시스템을 더 쉽게 사용할 수 있다.

Pupustory Dev/Design Patterns

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Pupustory Dev/Design Patterns

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

커맨드 패턴(Command Pattern)

방송 스튜디오 조명회사 (주) pupustory에서는 이번에 2MB방송국 개국을 맞아 새로 만든 스튜디오의 조명공사를 들어갔다. 조명은 총 5개로 구성되어 있고, 5개의 조명은 기본적인 '켜짐, 꺼짐'기능을 갖고 있고, 5개의 조명은 개발적인 제어도 가능하고, 전체조명의 '켜짐, 꺼짐'도 가능해야 한다. 조명의 편리한 사용을 위해 '리모컨 하나로 모든 조작이 가능 하도록' 요구 하였다.

먼저 우리가 살펴볼 사항은 1. '조명' 5개와 그 조명을 관리하는 2. 모듈(Command), 사용에 편리한 기능의 3. 리모컨이 필요하다. 일단 각각의 조명은 기본적인 On,Off(켜짐, 꺼짐)기능이 동일하게 들어가므로 이부분을 통합할 수 있다. 즉 interface의 이용이 가능하단 이야기다. 그리고 리모컨에선 모듈들을 모아 관리하고, 경우에 따라 전체 On, 전체 Off, 개별적인 조명의 On,Off기능을 수행하도록 하면 될 것이다. 간추려 핵심만 지적하면 다음과 같다.

1. 5개의 조명이 있다.
2. 5개의 조명은 on,off의 기능이 있다.
3. 리모컨을 통해 5개의 조명을 모두, 혹은 개별적인 제어가 가능 해야 한다.
4. 경우에 따라선 on,off기능 외의것도 들어갈 수 있다.

우리에게 필요한건 '조명, 조명의 on,off모듈, 이것을 관리할 리모컨 이렇게 필요하다. 여기서 공통점을 끄집어 내자면 '조명의 on off기능은 공통으로 적용'된다는 점이다. 그렇다면 이것을 '추상화'하는것이 가
능할 것이다. 그럼 이에맞게 코드를 작성해 보자.

조명 클레스 [Light.java] package pupustory.designpatterns.command; // 기본적인 조명 클레스 입니다. public class Light { String status; // 조명 켜짐 public void LightOn() { this.status = "is ON!"; } // 조명 꺼짐 public void LightOff() { this.status = "is OFF!"; } // 조명 상태를 알 수 있습니다. public String toString() { return this.hashCode() + " light " + this.status; } }
커맨드(조명제어모듈) 상위 클레스 [Command.java] package pupustory.designpatterns.command; public interface Command { // 실행메소드입니다. on,off를 경우에 따라 // 구현할 클레스에서 유연하게 작동시키도록 하죠. // 만약 on,off이외의 추가 기능이 들어간다면 // 여기에 추가해 구현하면 될 것 입니다. public void execute(); }

구현된 off(커맨드) 클래스 [LightOffCommand.java] package pupustory.designpatterns.command; public class LightOffCommand implements Command { private Light light = null; // 생성자로 조명 객체를 받습니다. public LightOffCommand(Light light) { this.light = light; } // 생성자로 받은 조명을 off상태로 돌립니다. public void execute() { light.LightOff(); System.out.println(light.toString()); } }
구현된 on(커맨드) 클래스 [LightOnCommand.java]package pupustory.designpatterns.command; public class LightOnCommand implements Command { private Light light = null; // 생성자로 조명 객체를 받습니다. public LightOnCommand(Light light) { this.light = light; } // 생성자로 받은 조명을 on상태로 돌립니다. public void execute() { light.LightOn(); System.out.println(light.toString()); } }
리모컨 클레스 [RemoteControl.java] package pupustory.designpatterns.command; public class RemoteControl { // 총 도명은 5개 입니다. final int MAX =5; // 켜지는 조명 모듈 private Command[] OnCommand = new Command[MAX]; // 꺼지는 조명 모듈 private Command[] OffCommand = new Command[MAX]; // 생성자로 꺼짐, 켜짐 모듈을 받습니다. public RemoteControl(Command[] OnCommand,Command[] OffCommand){ this.OnCommand = OnCommand; this.OffCommand = OffCommand; } // 전체 켜짐 public void LightAllOn() { for (int i=0; i<MAX; i++) { OnCommand[i].execute(); } } // 전체 꺼짐 public void LightAllOff() { for (int i=0; i<MAX; i++) { OffCommand[i].execute(); } } // 단일 조명 켜짐 public void LightOn(int lightNO) { OnCommand[lightNO].execute(); } // 단일 조명 꺼짐 public void LightOff(int lightNO) { OnCommand[lightNO].execute(); } }
실행 프로그램 [StartApp.java] package pupustory.designpatterns.command; public class StartApp { public static void main (String args[]) { final int MAX = 5; // 총 조명은 5개 입니다. Light light[] = new Light[MAX]; // 조명 켜짐. Command lightOn[] = new LightOnCommand[MAX]; // 조명 꺼짐. Command lightOff[] = new LightOffCommand[MAX]; for (int i=0; i<MAX;i++) { // 조명 객체를 생성 light[i] = new Light(); // 조명 켜짐. 생성자에 조명을 보냅니다. lightOn[i] = new LightOnCommand(light[i]); // 조명 꺼짐. 생성자에 조명을 보냅니다. lightOff[i] = new LightOffCommand(light[i]); } // 리모컨 생성. 생성자로 command를 넘깁니다. RemoteControl remote = new RemoteControl(lightOn,lightOff); System.out.println("=== all light On! ==="); remote.LightAllOn(); System.out.println("=== all light Off ==="); remote.LightAllOff(); System.out.println("===3 light only ON==="); remote.LightOff(3); for (int i=0;i<MAX; i++) { System.out.println(light[i].toString()); } } }

먼저 조명클레스는 큰 내용이 없다. on,off의 상태는 status를 통해 확인 할 것이다. 그리고 execute()가 정의되어 있는 커맨드(Command)는 '변경을 실행'한다고 생각하면 된다. 여기에서 변경은 on,off를 의미한다. 그것을 상속받아 구현된 on,off모듈인 LightOffCommand와 LightOnCommand은 Command를 상속받아 execute를 구현한다. 여기에 execute는 on인가? off인가? 를 판단하여 구현하면 될 것이다. 만약 새로운 명령어가 있다면? 여기에 추가하면된다. 어차피 레퍼런스로 사용할 Command에선 execute를 수행할 것이고, 객체에서 할 일에 대한 메소드를 정의하기 때문에 추가던 삭제던 코드의 큰 변화는 없다.

Pupustory Dev/Design Patterns

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[head first design patterns]내용을 일부 인용 했습니다.

추상 팩토리 패턴(Abstract Factory Pattern)

인터페이스를 이용하여 서로 연관되는,또는 의존하는 객체를 구상 클레스를 지정하지 않고도 생성할 수 있다

장난감 제조업체 (주)pupustory toys 에서 팩토리 메소드 패턴(이전 포스트를 먼저 참조하세요!)을 이용해 국가별로 장난감을 별도로 생산할 것을 생각해 이용했다. (만약 절대 확장이 없는 경우라면 복잡한 관계나 인터페이스 레퍼런스를 이용할 필요가 없을 수도 있다. 간단히 해결할 문제를 디자인 패턴을 적용한답시고 더 지저분 하게 할 수도 있기 때문이다. 뭐든 오버하면 안한만 못하니까 ..) 그런데 한가지 문제가 생겼다. 유럽 공장 클레스를 살펴보자

package pupustory.designpatterns.factory.def; public class ToyFactory_eu extends PupustoryFactory { public PupustoryToys createToy(String toyType) { PupustoryToys toy = null; if ("Toy01".equals(toyType)) { toy = new Toy_eu(); } else if ("Toy02".equals(toyType)) { // 차후 2호에 대한 클레스를 작성 후 조건에 기입 합니다. } toy.insertMenual(); // 이부분에서 공장장이 임의로 수정할 수 있어요! toy.setPack(); // 이부분도 그렇구요! 여기서 처리하면 안될꺼같군요! return toy; } }

장난감을 만들고 메뉴얼을 넣고, 포장을 하는 부분은 해당 지역의 국가에 있는 공장에서 이루어 졌다. 그런데 이번에 회사 방침에 따라 '우리회사 대주주 2MB께서 "대한민국 국민이 '삽'에대해 안좋은 감정이 많은 것 같다. 모든 장난감에 '삽'을 추가해 땅파기의 진리를 아이부터 깨닳게 하자!" 는 취지로 한국은 물론 유럽 공장까지도 .. 앞으로 추가될 수백 국가의 공장에 추가하기로 했습니다. 그리고 '임의의 다른 삽'으로 추가하지 않고, '공식 공장 지정 삽'으로 넣도록 변경하라고 합니다.

하나씩 살펴보죠. 먼저 바뀌어야 할 부분은 어떤것일까요?

1. 상위 장난감 클레스(PupustoryToys)에 '삽'이 추가되어야 한다.

2. 국가마다 삽이 틀리다. 따라서 삽은 국가별 공장에서 '구현'하되, 삽을 추가하는 부분은 '임의 수정이 되지 않도록'해야한다.

3. 디자인 패턴에 맞게 '구현'보다는 '추상'에 중점을 둬야 한다.

먼저 상위 장난감 클레스에 '삽'을 추가하자.

장난감 최상위 클레스[PupustoryToys.java]

package pupustory.designpatterns.factory.abstract_; public abstract class PupustoryToys { // 장난감 이름과 가격 필드 private String toyName; private int toyValue; // 삽 아이템이 추가되었군요! protected String Shovel ="삽을들자! 그리고 땅을파자! 그리고 물을 채우자!"; // 삽정보를 수정하는 부분 입니다. // 생성자로 공장을 받는군요! 이유는 아래 설명해뒀어요! IShvelFactory factory; // 생성자로 공장(삽아이템 추가부분)을 받는군요! 이유는 아래 설명해뒀어요! public PupustoryToys(IShvelFactory factory) { // 공장으로 부터 삽정보를 받아 수정합니다 // 엄밀히 따지면 넘어오는 것은 '삽공장'이죠! this.factory = factory; this.Shovel = factory.getShvel(); } public String getToyName() { return toyName; } protected void setToyName(String toyName) { this.toyName = toyName; } public int getToyValue() { return toyValue; } protected void setToyValue(int toyValue) { this.toyValue = toyValue; } public void insertMenual() { System.out.println(this.toyName+" 제품 설명서를 추가합니다."); } public void setPack() { System.out.println(this.toyName+"제품을 포장합니다."); } public String getShovel() { return Shovel; } }

유럽형 장난감 클레스[Toy_eu.java]

package pupustory.designpatterns.factory.abstract_; public class Toy_eu extends PupustoryToys { // 생성자를 통해 넘어온 공장(삽공장)을 상위 클레스 생성자에게 넘깁니다. public Toy_eu(IShvelFactory factory) { super(factory); setToyName("pupustory EU toy"); setToyValue(20000); } }

한국형 장난감 클레스[Toy_ko.java]

package pupustory.designpatterns.factory.abstract_; public class Toy_ko extends PupustoryToys { // 생성자를 통해 넘어온 공장(삽공장)을 상위 클레스 생성자에게 넘깁니다. public Toy_ko(IShvelFactory factory) { super(factory); setToyName("pupustory 장난감 01호"); setToyValue(10000); } }

다음은 좀 까다롭다. 구현한 공장에서 하는것이 아니라면 어떻게 해야할까..? 여기서 한가지 더 생각해 볼것은 '공식 공장 지정 삽'이라는 부분이다. 즉 공장에서 '삽'에 대해 지정은 했지만, 이것이 '공장 로직엔 제외'된다는 것이다. 그렇다면 어디서 하는게 좋을까?

공장에서 알 수 없도록 하기 위해 공장 로직에서 빠진다면 '공장이 아닌 다른 곳'에서 이것을 관리해야 할것이다. 따라서 '삽공장'클레스를 만든 후 이것을 '공장'이 갖고 있는 구조로 하면 쉽게 해결 된다. 공장은 삽공장 정보를 갖고 있고, 이것을 '장난감'에 넣어주기만 하면된다. 그럼 넣는 공정은어디에..? 이쯤되면 예상했겠지만 '장난감 클레스'에 '공장 클레스(가 가지고 있는 삽공장)'가 인자로 넘겨주고, '장난감 클레스'의 생성자에서 '공장 클레스에 있는 삽공장 레퍼런스'을 넣어주면 되는 것 이다.

생성자로 인자를 전달 하므로, 실제 장난감 객체가 생성되는 부분이 추가될 것 이고, 삽공장은 '공식 지정 삽'의 정보(엄밀히 따지면 삽의 객체를 반환하는 메소드)를 가지고 있을 것이다. 이제 해결책이 생겼다. 그럼 변경된 코드를 살펴보자.

삽공장 인터페이스 [IShvelFactory.java]

package pupustory.designpatterns.factory.abstract_; public interface IShvelFactory { public String getShvel(); }

유럽형 삽공장 [ShvelFactory_eu.java]

package pupustory.designpatterns.factory.abstract_; public class ShvelFactory_eu implements IShvelFactory { public String getShvel() { return "유럽 지형에 강한 삽이에요!"; } }

한국형 삽공장[ShvelFactory_ko.java]

package pupustory.designpatterns.factory.abstract_; public class ShvelFactory_ko implements IShvelFactory { public String getShvel() { return "한국지형에 강한 삽이에요!"; } }

공장 최상위 클레스 [PupustoryFactory.java]

package pupustory.designpatterns.factory.abstract_; abstract public class PupustoryFactory { // 이건 그냥 interface로 해도 무관합니다. 구현된 메소드가 없으니까요. abstract public PupustoryToys createToy(String toyType); }

장난감 최상위 클레스 [PupustoryToys.java]

package pupustory.designpatterns.factory.abstract_; abstract public class PupustoryFactory { // 이건 그냥 interface로 해도 무관합니다. 구현된 메소드가 없으니까요. abstract public PupustoryToys createToy(String toyType); }

유럽형 장난감 [ToyFactory_eu.java]

package pupustory.designpatterns.factory.abstract_; public class Toy_eu extends PupustoryToys { // 생성자를 통해 넘어온 공장(삽공장)을 상위 클레스 생성자에게 넘깁니다. public Toy_eu(IShvelFactory factory) { super(factory); setToyName("pupustory EU toy"); setToyValue(20000); } }

한국형 장난감 [ToyFactory_ko.java]

package pupustory.designpatterns.factory.abstract_; public class Toy_ko extends PupustoryToys { // 생성자를 통해 넘어온 공장(삽공장)을 상위 클레스 생성자에게 넘깁니다. public Toy_ko(IShvelFactory factory) { super(factory); setToyName("pupustory 장난감 01호"); setToyValue(10000); } }

유럽형 공장 [ShvelFactory_eu.java]

package pupustory.designpatterns.factory.abstract_; public class ToyFactory_eu extends PupustoryFactory { private IShvelFactory shvelFactory = new ShvelFactory_eu(); public PupustoryToys createToy(String toyType) { PupustoryToys toy = null; if ("Toy01".equals(toyType)) { toy = new Toy_eu(shvelFactory); } else if ("Toy02".equals(toyType)) { // 차후 2호에 대한 클레스를 작성 후 조건에 기입 합니다. } toy.insertMenual(); toy.setPack(); return toy; } }

한국형 공장 [ShvelFactory_ko.java]

package pupustory.designpatterns.factory.abstract_; public class ToyFactory_ko extends PupustoryFactory { private IShvelFactory shvelFactory = new ShvelFactory_ko(); public PupustoryToys createToy(String toyType) { PupustoryToys toy = null; if ("01호".equals(toyType)) { toy = new Toy_ko(shvelFactory); } else if ("02호".equals(toyType)) { // 차후 2호에 대한 클레스를 작성 후 조건에 기입 합니다. } toy.insertMenual(); toy.setPack(); return toy; } }

실행 프로그램 [StartApp.java]

package pupustory.designpatterns.factory.abstract_; public class StartApp { public static void main(String[] args) { // 한국에서 생산되는 공장 인스턴스 PupustoryFactory FactoryKo = new ToyFactory_ko(); // 유럽에서 생산되는 공장 인스턴스 PupustoryFactory FactoryEu = new ToyFactory_eu(); // 한국형 장난감 01호를 생산 합니다. PupustoryToys toy01_ko = FactoryKo.createToy("01호"); // 유렵형 장난감 Toy01을 생산 합니다. PupustoryToys toy01_eu = FactoryEu.createToy("Toy01"); // 정보를 출력 합니다. System.out.println(toy01_ko.getToyName() +" <가격>\t "+ toy01_ko.getToyValue()); System.out.println(toy01_ko.getToyName() +" <삽?!>\t "+ toy01_ko.getShovel()); System.out.println(toy01_eu.getToyName() +" <가격>\t "+ toy01_eu.getToyValue()); System.out.println(toy01_ko.getToyName() +" <삽?!>\t "+ toy01_eu.getShovel()); } }

코드의 주석을 살펴보면 보다 이해가 빠를 것 이다. 그렇다면 과연 이것은 어떤 의미에서 더 좋을까 ..? 일단 팩토리는  말 그대로 '공장'이므로 모두 같은 제품이 찍어저 나올 것 이다. (물론 그러해야만 하고..) 하지만 여기에 좀 더 추가되 생성되는 객체(제품)에 연관된 작업이 있다고 할 수도 있고, 무엇보다 '공장 클레스'로부터 어떤 작업(여기선 삽 설정)을 하는지 알 필요가 없어진다. 즉, 캡슐화가 가능한 것 이다.

그리고 생성된 객체(제품)은 공장으로 부터의 의존도가 없어진다.의존도가 사라지는 것은 매우 유용하다. 바로 구현된 클레스들에게 보다 정확한 역할을 부여하기 때문이다.

Pupustory Dev/Design Patterns

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[head first design patterns]내용을 일부 인용 했습니다.

팩토리 메소드 패턴(Factory Method Pattern)

장난감 제조업체 (주)pupustory toys 에서는 이번에 새로운 공장설비 프로그램을 작성하기로 했다. 기존의 낡은 방식에서 벗어나 이번엔 좀 더 유연하고 국가별로 서로다른 제품이 생산될 수 있도록 하는 프로그램으로 접근하기로 했다. 그렇게 나온 코드는 다음과 같다.

공장 상위 클레스[PupustoryFactory.java] package pupustory.designpatterns.factory.oldversion; abstract public class PupustoryFactory { // 이건 그냥 interface로 해도 무관합니다. 구현된 메소드가 없으니까요. abstract public PupustoryToys createToy(String toyType); }
장난감 상위 클레스[PupustoryToys.java] package pupustory.designpatterns.factory.oldversion; public abstract class PupustoryToys { // 장난감 이름과 가격 필드 private String toyName; private int toyValue; public String getToyName() { return toyName; } protected void setToyName(String toyName) { this.toyName = toyName; } public int getToyValue() { return toyValue; } protected void setToyValue(int toyValue) { this.toyValue = toyValue; } public void insertMenual() { System.out.println(this.toyName+" 제품 설명서를 추가합니다."); } public void setPack() { System.out.println(this.toyName+"제품을 포장합니다."); } }
한국 공장 클레스 [ToyFactory_ko.java] package pupustory.designpatterns.factory.oldversion; public class ToyFactory_ko extends PupustoryFactory { // 한국 공장 클레스 public PupustoryToys createToy(String toyType) { // 모든 장난감은 PupustoryToys를 상속받아 구현 합니다. // 따라서 레퍼런스는 PupustoryToys로 구성하죠. // 내부에 어떤 장난감인지는 알 필요가 없습니다. // 그저 인자를 통해 들어온 타입에 따라 장난감 인스턴스를 생성하고 반환하죠. PupustoryToys toy = null; if ("01호".equals(toyType)) { toy = new Toy_ko(); } else if ("02호".equals(toyType)) { // 차후 2호에 대한 클레스를 작성 후 조건에 기입 합니다. // 위에 보이던대로 작성하면 손쉽게 할 수 있죠. } // 메뉴얼을 넣고 포장을 합니다. toy.insertMenual(); toy.setPack(); // 이제 장난감을 반환 합니다. return toy; } }
유럽 공장 클레스[ToyFactory_eu.java] package pupustory.designpatterns.factory.oldversion; public class ToyFactory_eu extends PupustoryFactory { // ToyFactory_ko.java와 같은 내용입니다. // 단지 국가가 틀려졌죠. 이제 장난감을 국가별로 별도로 관리하는것이 가능해졌습니다. // 사실 이렇게 안해도 되긴 하죠. 하지만 제품이 수백가지가 되고 한다면 // 이와같은 분리를 통해 관리를 해야 할 것 입니다. public PupustoryToys createToy(String toyType) { PupustoryToys toy = null; if ("Toy01".equals(toyType)) { toy = new Toy_eu(); } else if ("Toy02".equals(toyType)) { // 차후 2호에 대한 클레스를 작성 후 조건에 기입 합니다. } toy.insertMenual(); toy.setPack(); return toy; } }
유럽에서 생산되는 장난감 Toy01[Toy_eu.java] package pupustory.designpatterns.factory.oldversion; public class Toy_eu extends PupustoryToys { // 생성자를 통해 장난감 이름과 가격을 정합니다. public Toy_eu() { setToyName("pupustory EU toy"); setToyValue(20000); } }
한국에서 생산되는 장난감 01호[Toy_ko.java] package pupustory.designpatterns.factory.oldversion; public class Toy_ko extends PupustoryToys { // 생성자를 통해 장난감 이름과 가격을 정합니다. public Toy_ko() { setToyName("pupustory 장난감 01호"); setToyValue(10000); } }
실행 프로그램 [StartApp.java] package pupustory.designpatterns.factory.oldversion; public class StartApp { public static void main(String[] args) { // 한국에서 생산되는 공장 인스턴스 PupustoryFactory FactoryKo = new ToyFactory_ko(); // 유럽에서 생산되는 공장 인스턴스 PupustoryFactory FactoryEu = new ToyFactory_eu(); // 한국형 장난감 01호를 생산 합니다. PupustoryToys toy01_ko = FactoryKo.createToy("01호"); // 유렵형 장난감 Toy01을 생산 합니다. PupustoryToys toy01_eu = FactoryEu.createToy("Toy01"); // 정보를 출력 합니다. System.out.println(toy01_ko.getToyName() +" <가격>\t "+ toy01_ko.getToyValue()); System.out.println(toy01_eu.getToyName() +" <가격>\t "+ toy01_eu.getToyValue()); } }

클레스가 여러가지 있지만 내부 내용들은 아주 단순하다. 간단히 설명하면 공장에 대한 상위 클레스(PupustoryFactory)가 존재 한다. 각 국가(ko, eu)에서는 상속받아 createToy()메소드를 구현 한다. (사실 이부분은 인터페이스로 해도 무관하다. 여러 코드를 더 넣었지만 보기에 가독성이  떨어질꺼같아 그냥 빼버렸다.) 그리고 createToy()에 인자로 넘어가는 toyType를 통해 생성하는 장난감을 확인 한다. 그리고 조건을 통해 타입에 대한 장난감을 생성하고 반환해 준다.

팩토리 패턴에서 사용된 팩토리는 어떠한 장난감이 생성되는지 알 수 없다. 그저 조건에 따라 레퍼런스에 장난감을 생성하고 그걸 반환해 주는 역할을 한다. 즉 장난감 내부에 어떤 로직이 있는지 알 수 없다는 것이다. 그저 생성 후엔 '메뉴얼을 넣고 포장을 한다.'정도만 알고 있다.

이렇게 정확히 역할을 분리함으로써 결합도가 낮아지기 때문에 보다 유연한 코드작성이 가능해 진다. 위 코드는 매우 단순하다. 국가별로 나눈 팩토리도 사실 하나로 묶어도 상관 없다. 하지만 나눈 이유는 무엇일까 ?

위 소스는 어차피 간단한 소스기 때문에 묶어도 상관 없지만 분류가 많아지고 내부로직이 바뀐다면? 예를들어 한국에서 생산된 장난감은 기본적으로 20%dc를 해준다고 가정 했을때 value필드에 가격을 내리는 로직이 추가되어야 할 것이다. 하나의 팩토리에 묶여있다면 이것은 모든부분을 일일이 찾아가 '한국 생산 공장 제품에 20%dc로직을 추가'해야 하는 제앙이 따르게 된다. 이러한 것을 방지할 수 있기 때문에 상위 클레스를 상속받아 이용하는것이 더 좋을 것이다.

Pupustory Dev/Design Patterns

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[head first design patterns]내용을 일부 인용 했습니다.

싱글턴 패턴(Singleton Pattern)

소프트웨어 전문 업체 (주)pupustory에서 이번에 새로 수주받은 프로그램은 '사원 출입 통제 프로그램'이다. 고객의 요구사항은 다음과 같다.

조건을 간단히 설명하면 회사 출입은 단 한개의 정문으로 들어올 수 있다. 차후 생길 여러개의 출입문(multi thread)에 대비해 만들어야 한다. 그리고 사원의 카드에 권한에 따라 출입여부가 결정 된다. 동시에 수백명이 한번에 몰릴 수도 있고, 어떨땐 한명도 접근하지 않을 수 있다.

이것과 비슷한것을 생각해보면 먼저 우리가 자주 사용한 DB POOL을 들 수 있다.DB에 대한 커넥션을 얻어오기 위해 POOL에 요청을 하고 미리 만들어진 인스턴스를 받아와 사용할 때 말이다. 이것을 풀어 얘기하면 결과적으로 우리가 만들려고 하는 프로그램과 같은 얘기가 된다. 출입 통제를 확인하는 인스턴스 하나를 두고, 사용자 권한을 확인해 출입 가능 여부를 확인하는 것이다. 코드를 살펴보자.

출입통제 프로그램 [GateApp.java] package pupustory.designpatterns.singleton.oldversion; public class GateApp { private static GateApp instance; // 본 출입문은 10 이상의 권한이 있어야 출입이 가능 함 private final int geteAuth = 10; // 외부에서 임의로 인스턴스를 생성할 수 없도록 private로 지정 함 private GateApp() {} // 동시에 여러 쓰레드에서 접근할 수 없도록 synchronized(동기화)함 public synchronized static GateApp getInstance(){ // 만약 instance가 null일경우(최초생성) 인스턴스를 하나 생성 함 if (instance == null) { instance = new GateApp(); } // 인스턴스 반환 return instance; } // 사용자 권한과 출입의 권한을 비교하는 메소드. // 사용자 권한이 출입 권한보다 크거나 같으면 출입을 허가 함 public boolean isAuth(int userAuth) { if (geteAuth <= userAuth) { return true; } else { return false; } } }
사원 권한 [UserInfo.java] package pupustory.designpatterns.singleton.oldversion; public class UserInfo { private String userName;//출입자 이름 private int userAuth;// 출입자 권한 // 사용자 정보의 생성자 public UserInfo(String userName, int userAuth) { this.userName = userName; this.userAuth = userAuth; } public String getUserName() { return userName; } public void setUserName(String userName) { this.userName = userName; } public int getUserAuth() { return userAuth; } public void setUserAuth(int userAuth) { this.userAuth = userAuth; } }
실행 프로그램 [StartApp.java]
package pupustory.designpatterns.singleton.oldversion; public class StartApp { public static void main(String args[]) { GateApp gate = GateApp.getInstance(); // 사원 50명을 생성 함 UserInfo[] user = new UserInfo[50]; // 무작위로 숫자 발생 java.util.Random ranAuth = new java.util.Random(); for (int i=0;i<user.length;i++) { // 사원에게 권한 무작위 적용 (0~19중 난수발생하여 권한 저장) user[i] = new UserInfo("사원"+i+"호",ranAuth.nextInt(20)); // 사원의 권한 확인(싱글턴 gateApp의 instance 이용) boolean hasAuth = gate.isAuth(user[i].getUserAuth()); if (hasAuth) { System.out.println(user[i].getUserName()+"님 출입 허용[" +user[i].getUserAuth()+"]"); } } } }

주석을 살펴보면 왜 저렇게 작성하게 된 것인지 알 수 있다. 생성자를 private로 함으로 써 외부에서 감히 객체를 생성할 수 없도록 했으며, 동기화 걸린 static 메소드인 getInstance()를 통해 생성된 인스턴스를 반환해 준다.(최초 호출시엔 당연히 인스턴스가 없으므로 null 여부를 확인 후 생성해 반환한다.)

다중 쓰레드에 의한 접근에도 본 프로그램은 문제가 없을 것이다. 왜냐하면 getInstance()부분에서 동기화가 되어 있으므로 동시에 접근해 instance를 두개 이상 생성할 수 없기 때문에 이정도로 프로젝트가 완료되어도 될 듯 하다.

그렇다면 이런 질문이 있을 수도 있다. '그냥 static로 이용해서 하면 안되나?'라고 .. 사실 static로 해도 문제가 안될 수도 있다. 위의 프로그램은 간단한 메소드 한개만 가지고 있다. 그런데 갑의 요구사항엔 다음과 같은 내용이 있었다.

즉, 어쩌면 인스턴스가 아예 생성되지 않을(사용을 전혀 안할수도) 있다는 얘기다. static로 할 경우 처음에 메모리에 올려버리기 때문에 한번도 사용하지 않는 인스턴스를 쓸대없이 올라와 있게 된다. 싱글턴 패턴은 이러한 낭비를 최대한 줄일수도 있고, 객체생성을 늦출수도 있다.또 static로 하게 되면 내부에서 사용되는 인스턴스는 반드시 static이여야 하므로 로직이 복잡하게 들어 간다면 모든 인스턴스를 static로 해주어야 하는데, 이것은 코드가 복잡해지고, 차후 수정시(혹은 일부분 재사용)제약을 받게 될 것이다.

싱글턴 패턴의 이용 분야는 여러가지 있겠지만 이정도면 충분히 설명이 되었다 생각된다. 이쯤에서 한번 살펴볼 사항이 있다. 바로 '성능'부분이다. 자바의 동기화는 '이왕이면 .. 이왕이면 ..'하며 반드시 필요한 부분에 사용하길 권장한다. 이유는 동기화가 걸리게 되면 성능이 엄청나게 저하되기 때문이다. 여기에 한가지 해결책이 있다.

향상된 출입 프로그램 [GateApp.java] package pupustory.designpatterns.singleton.newversion; public class GateApp { // volatile키워드를 통해 원자성 보장 private static volatile GateApp instance; // 본 출입문은 10 이상의 권한이 있어야 출입이 가능 함 private final int geteAuth = 10; // 외부에서 임의로 인스턴스를 생성할 수 없도록 private로 지정 함 private GateApp() {} // 메소드엔 동기화를 제거 함 public static GateApp getInstance(){ // 만약 instance가 null일경우 동기화 블럭 수행 if (instance == null) { // instance가 null이므로 동기화 블럭에서 객체 생성 synchronized (GateApp.class) { // 동기화 블럭에 동시에 접근해 대기중인 쓰레드가 있을 경우 // 여기에서 한번 더 확인하지 않으면 2개가 생길 수 있음 // 따라서 한번 더 확인 후 인스턴스를 생성 함 if (instance == null) { instance = new GateApp(); } } } // 인스턴스 반환 return instance; } // 사용자 권한과 출입의 권한을 비교하는 메소드. // 사용자 권한이 출입 권한보다 크거나 같으면 출입을 허가 함 public boolean isAuth(int userAuth) { if (geteAuth <= userAuth) { return true; } else { return false; } } }

위 코드는 먼저 getInstance()부분에 동기화가 제거 되어있다. 그리고 조건을 확인 한 후 객체가 null일경우 동기화 블럭을 수행한다. 수행시 한번 더 확인하는 이유는 위에서 설명한데로 동기화 블럭을 진행중일때 동기화 블럭에 대기중인 객체가 있을 수 있기때문에 한번 더 확인하는 것이다.

여기서 눈의 띄는 부분은 volatile 키워드이다. 이것은'원자성을 보장'한다고 되어있다. 이에 대해 간단히 말하자면 우리가 int변수를 선언하면 32bit 의 영역이 생기게 된다. 만약 double를 선언하면..? 64bit가 선언되어야 하는데 이것은 32bit를 2개 붙혀둔 모양이다. 다시말해 [32bit][32bit]이런식으로 구성되어 있는데 만약 두개의 프로그램에서 여기에 동시에 접근했다고 가정 하자.

프로그램 a에선 앞의 [32bit]에 접근했고, b에선 뒤의 [32bit]에 접근 했다면 double의 값은 프로그램a의 값도 아니고 b의 값도 아닌 전혀 엉뚱한 값이 들어가 있게 된다. 이것을 보호하는 키워드가 바로 volatile인것이다. 이런 경우는 정말 java에서는 있기 매우 힘든경우고 없다고 해도 과언이 아닐듯 하다. 하지만 instance의 경우엔 생성자를 호출하고, 객체가 생성되는 시간을 생각해 본다면 정밀한(?) 멀티 쓰레딩 프로그램에선 보다 나은 안정성을 보장할 것으로 보인다.

Pupustory Dev/Design Patterns

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[head first design patterns]내용을 일부 인용 했습니다.

데코레이터 패턴 (Decorator Pattern)

MP3 player 개발업체인 (주)pupustory에선 제품가격에 대해 다음과 같은 방법으로 책정 프로그램을 사용하고 있다.

최상위 클레스를 상속받고, 하위 클레스에서 제품에 들어간 부속들의 가격을 더한 값을 cost()메소드를 통해 반환한다.

Mp3Player.java [Mp3제품 클레스(상위)] package pupustory.designpatterns.decorate; public abstract class Mp3Player { // MP3 제품 모델 이름 private String MdlName = "It's default MP3 player model name"; // 제품에 들어가는 부품들 가격 private int partsA = 5000; private int partsB = 6000; private int partsC = 7000; private int partsD = 8000; private int partsE = 9000; private int partsF = 10000; // MP3 제품에 대한 가격 정보 (출시되는 제품에 맞춰 책정 됩니다.) public abstract int cost(); public String getMdlName() { return MdlName; } // 상속받는 클레스에서 이름을 변경 합니다. protected void setMdlName(String MdlName) { this.MdlName = MdlName; } // 각각의 부품에 대한 가격을 리턴하는 메소드 protected int getPartsA() { return partsA; } protected int getPartsB() { return partsB; } protected int getPartsC() { return partsC; } protected int getPartsD() { return partsD; } protected int getPartsE() { return partsE; } protected int getPartsF() { return partsF; } }
Mp3Mdl_A.java [모델A 클레스] package pupustory.designpatterns.decorate; public class Mp3Mdl_A extends Mp3Player { public Mp3Mdl_A() { setMdlName("모델 A MP3 Player"); } // .. other code public int cost() { // 모델A엔 부품 A,B,C가 추가된 가격과 기본가격 10000원이 추가되어 책정 됨 return getPartsA()+getPartsB()+getPartsC()+10000; } // .. other code }
Mp3Mdl_B.java [모델B 클레스] package pupustory.designpatterns.decorate; public class Mp3Mdl_B extends Mp3Player { public Mp3Mdl_B() { setMdlName("모델 B MP3 Player"); } // .. other code public int cost() { // 모델A엔 부품 A,B,C,D,E가 추가된 가격과 기본가격 15000원이 추가되어 책정 됨 return getPartsA()+getPartsB()+getPartsC()+getPartsD()+getPartsE()+15000; } // .. other code }
Mp3Mdl_C.java [모델C 클레스] package pupustory.designpatterns.decorate; public class Mp3Mdl_C extends Mp3Player { public Mp3Mdl_C() { setMdlName("모델 C MP3 Player"); } // .. other code public int cost() { // 모델A엔 부품 A,B,C,D,E,F가 추가된 가격과 기본가격 20000원이 추가되어 책정 됨 return getPartsA()+getPartsB()+getPartsC()+getPartsD()+getPartsE()+getPartsF()+20000; } // .. other code }
StartApp.java [실행 프로그램] package pupustory.designpatterns.decorate; public class StartApp { public static void main(String[] args) { Mp3Player[] mp3Player = {new Mp3Mdl_A(),new Mp3Mdl_B(),new Mp3Mdl_C()}; for (int i=0;i<mp3Player.length;i++) { System.out.println("mp3제품 명 :"+mp3Player[i].getMdlName() + "\t" + "mp3제품 가격 :"+mp3Player[i].cost()); } } }

지금까지 회사에 부품은 총 A~F까지 존재했지만 앞으로 추가될 부품은 계속 늘어날 것으로 예상 된다.

사실 그냥 사용하는것도 나쁘진 않다. 어차피 상위 클레스에 존재하므로, 그것을 상속받아 cost()에서 반환할때 값만 더해주면 문제가 없으니 말이다.

하지만 생각해보자. 우리는 기본적으로 OOP에 대해 공부할때 '확장의 용이성'에 대해 언급한 적이 있을 것이다.(기억 안나면 그냥 넘어가자..)

위 코드방식을 계속 고집한다면 상위 클레스의 덩치는 계속 커져가고, 결과적으로 이것은 확장성을 제로에 가깝다고 할 수 있다.

또 부속이 늘어나 1000가지가 되었다고 가정 하자. 하지만 제품에 들어가는 부속은 단 2~3가지라고 가정할때 나머지 부속에 대한 정보를 상속받아 하위클레스가 가지고 있는것은 쓸대없는 낭비일 뿐 아니라 보안상으로도 별로 보기좋은 모습은 아니다.

이럴때 생각해 볼 수 있는것이 '데코레이터 패턴'이다.

우리의 문제점을 정확히 해결해 줄 수 있는 패턴인듯 하다. 일단 주목할 것은 '추가적인 요건을 동적으로 첨가'한다는데 있다.

우리의 부속품을 첨가한다 가정할때 동적으로 첨가하므로 상위 클레스의 덩치가 커지는(혹은 변경되는)일을 막을 수 있다.

물론 '서브클레스에서 만드는것을 통해 기능을 유연하게 확장'할 수 있으므로 문제점에 정확한 해결책 일 것이다.

기본적 골격의 코드는 다음과 같다.
Mp3Player.java [Mp3제품 클레스(상위)] package pupustory.designpatterns.decorate.use; public abstract class Mp3Player { // MP3 제품 모델 이름 private String MdlName = "It's default MP3 player model name"; // MP3 제품에 대한 가격 정보 (출시되는 제품에 맞춰 책정 됩니다.) public abstract int cost(); public String getMdlName() { return MdlName; } // 상속받는 클레스에서 이름을 변경 합니다. protected void setMdlName(String MdlName) { this.MdlName = MdlName; } }
Mp3Part_A.java [부속품A 클레스] package pupustory.designpatterns.decorate.use; public class Mp3Part_A extends Mp3Player { Mp3Player mp3Player; public Mp3Part_A(Mp3Player mp3Player) { this.mp3Player = mp3Player; } public int cost() { // 부품A의 가격 입니다. return mp3Player.cost()+5000; } }
Mp3Part_B.java [부속품B 클레스] package pupustory.designpatterns.decorate.use; public class Mp3Part_B extends Mp3Player { Mp3Player mp3Player; public Mp3Part_B(Mp3Player mp3Player) { this.mp3Player = mp3Player; } public int cost() { // 부품B의 가격 입니다. return mp3Player.cost()+6000; } }
Mp3Part_C.java [부속품C 클레스] package pupustory.designpatterns.decorate.use; public class Mp3Part_C extends Mp3Player { Mp3Player mp3Player; public Mp3Part_C(Mp3Player mp3Player) { this.mp3Player = mp3Player; } public int cost() { // 부품C의 가격 입니다. return mp3Player.cost()+7000; } }
Mp3Mdl_A.java [부속품A 클레스] package pupustory.designpatterns.decorate.use; public class Mp3Mdl_A extends Mp3Player { public Mp3Mdl_A() { this.setMdlName("mp3플레이어 모델 A"); } public int cost() { // 모델A의 가본가격은 10000원입니다. return 10000; } }
Mp3Mdl_B.java [부속품B 클레스] package pupustory.designpatterns.decorate.use; public class Mp3Mdl_B extends Mp3Player { public Mp3Mdl_B() { this.setMdlName("mp3플레이어 모델 B"); } public int cost() { // 모델B의 가본가격은 15000원입니다. return 15000; } }
Mp3Mdl_C.java [부속품C 클레스] package pupustory.designpatterns.decorate.use; public class Mp3Mdl_C extends Mp3Player { public Mp3Mdl_C() { this.setMdlName("mp3플레이어 모델 C"); } public int cost() { // 모델C의 가본가격은 20000원입니다. return 20000; } }

위 코드를 보면 클레스가 많이 나뉘어 있어 보기 어려울 수도 있다. 하지만 최상위 클레스 Mp3Player와 그에대한 부품(Mp3Part..), 기본 제품(Mp3Mdl..)로만 나뉜 쉬운 구조다.

위 구조에서 보는바와 같이 먼저 Mp3Player에 cost() 메소드를 부품과 제품 모두 상속받아 가격을 책정했다.

여기서 '기본 제품'과 '부품'의 차이점은 생성자에서 볼 수 있다. 먼저 기본제품은 기본생성자가 생략되어 있다. 하지만 부품에선 상위 클레스 Mp3Player타입의 인자를 받는다.

이것은 '기본 제품을 생성자에서 인자로 받아 제품을 가지고 있는구조'라고 할 수 있다.

또다른 차이점은 바로 cost() 메소드이다. '기본 제품'은 단순한 자신의 값만 반환하지만 부품은 '자신이 생성자로 넘겨받은 (바로 기본제품!)의 가격에 자신의 가격을 더해서 반환한다.

이러한 구조로 되어있으므로 우리가 사용할땐 '기본 제품'을 '부품'클레스로 감싸서(생성자로 인자른 넘겨서)사용하는 것으로 부품이 추가될때마다 기존에 추가된 것을 가지고 있는 객체를 넘겨주면 된다.

내부적으로 이것은 부품이 넘어온 부품을 가지고 있고, 그 부품은 또다시 넘어온 부품을 가지고 있는식으로 되어있다.

즉, 최종적으로 외부에서 cost() 메소드를 호출하면 그 메소드는 '기본 제품'까지 내부적으로 계속 호출하며 가격을 추가하게 되고, 모두 추가된 값을 돌려받는 것이다.

어쩌면 '이것은 재귀호출인가..?'라고 생각할지 모르지만 전혀 틀리다. 재귀호출은 자신의 메소드를 계속 호출하여 깊이 들어가는것을 의미한다.

하지만 이것은 객체가 자신의 내부에 객체를 갖고있고,또 그 객체는 또다른 객체를 갖고있는 형식이다.
(말이 좀 어렵다. 하지만 코드를 계속 보고, 또는 직접 작성해보면 이해가 더 빠를 것이다.)

디자인 원칙

핵심정리

Pupustory Dev/Design Patterns

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[head first design patterns]내용을 일부 인용 했습니다.

옵저버 패턴 (Observer Pattern)

이 글을 읽는 사람은 '스타크래프트'를 한번이라도 해보거나 혹은 구경이라도 해본 적이 있을 것이다.

가장 편하게 설명하자면 여기에 등장하는 유닛인 '옵저버'를 패턴으로 만든다고 생각 하면 될 것이다.

Q. 그렇다면 생각해 보자. 스타크래프트에서 옵저버가 하는 일은 무엇인가 ..?
A. '클록킹 유닛을 찾는다.'

Q. ... 물론 그렇다. 하지만 클록킹 유닛을 찾는 것 외에 더 기본적으로 무엇을 하는가 ..?
A. '상대방을 관찰 한다.'

정확하다. 옵저버에 대한 사전적 뜻은 '관찰자'인 것이다. 우리는 프로그래밍을 한다.

그렇다면 프로그래밍에서 관찰한다는 것은 무엇에 해당하는가? 바로 객체들의 상태를 관찰한다는 의미이다.

이것은 우리가 흔히 사용하는 'windows'에서 쉽게 볼 수 있다.

예를들면 인터넷으로 영화를 다운받는다고 생각 하자..

탐색기를 열어 하드디스크 용량을 보고 있으면.. 얼마 단위로 용량이 착착 바뀌는 것을 알 수 있다.

이런 것을 구현할 수 있게 해주는 패턴이다.(풀링과 푸쉬방식의 차이는 있을 수 있다. 이부분은 차후 설명)

그렇다면 실제 어떤 문제에 대해 옵저버 패턴을 구현하는지 살펴보자.

먼저 옵저버 패턴은 우에 설명한 대로 1:n의 의존적 관계이다. 하나의 '주제'가 있다면 그것에 연관된 다른 객체들이 있고,

주제의 상태가 바뀌게 되면 다른 객체들은 바뀐 주제의 상태값을 받아오는 방식인 것이다.
(받아온 후 해당 객체에선 바뀐값에 대한 갱신과 기타 다른 연산이 있을 수 있다.)

이전에 작성된 스트래티지 패턴을 다시 살펴보면 우리는 느슨한 결합을 통해 얻은 점이 많이 있다.

예제로 사용할 코드는 '신문사'와 '신문구독자' 관계에서 도출된 내용을 기준으로 작성 되었다.

'신문배포사' (이하 신문사)는 신문구독자(이하 구독자)에게 2가지 정보를 바로바로 알려주게 된다.

그것은 '새로운 뉴스 건, 갱신 시간'을 알려주게 된다.

코드는 아래와 같으며 이번에도 느슨한 결함을 통해 옵저버 패턴을 구현하게 되면 다음과 같은 코드가 작성 될 것이다.
(단, 신문사에서 의 상태 변경(뉴스추가)은 setNewsUpdate()  메소드를 호출하기로 했다고 한다.)

INewsPaprCmpny.java [신문사 인터페이스] package pupustory.designpatterns.observer; public interface INewsPaprCmpny { // 구독자 추가 public void addReader(INewsReader reader); // 구독자 배열 추가 public void addReader(INewsReader[] reader); // 구독자 해지 public void removeReader(INewsReader reader); // 구독자에게 변경을 알림 public void notifyReaders(); // 신문사 정보 갱신 public void setNewsUpdate(int updateCount); // 신문사 정보 출력 public void display(int updateCount); }
INewsReader.java [구독자 인터페이스] package pupustory.designpatterns.observer; public interface INewsReader { // 신문사 정보가 갱신되면 호출 됨 public void updateNews(java.util.Date NewsUpdateTime, int NewsCount); // 구독자가 받은 신문 정보 출력 public void display(); }
NewsPaprCmpny.java [신문사 구현된 클레스] package pupustory.designpatterns.observer; public class NewsPaprCmpny implements INewsPaprCmpny { private java.util.List<INewsReader> readerList = null; private java.util.Date NewsUpdateTime = null; private int NewsCount; public NewsPaprCmpny() { // 구독자를 ArrayList에 보관함 readerList = new java.util.ArrayList<INewsReader>(); NewsUpdateTime = new java.util.Date(); NewsCount = 0; } public void addReader(INewsReader reader) { // 구독 추가 readerList.add(reader); } public void addReader(INewsReader[] reader) { // 구독자 배열 추가 for (int i=0; i<reader.length;i++) { readerList.add(reader[i]); } } public void removeReader(INewsReader reader) { // 구독자 삭제 readerList.remove(reader); } public void notifyReaders() { // 모든 구독자에게 updateNews() 호출 for (int i=0,count = readerList.size(); i<count; i++) { INewsReader reader = (INewsReader)readerList.get(i); NewsUpdateTime = new java.util.Date(); reader.updateNews(NewsUpdateTime, NewsCount); } } // 신문정보 갱신 public void setNewsUpdate(int updateCount) { NewsCount += updateCount; this.display(updateCount); // 구독자에게 알립니다. this.notifyReaders(); } // 현재 신문사 정보를 출력 public void display(int updateCount) { System.out.println("뉴스 배포사에서 새로운 뉴스를 추가했습니다 !!"); System.out.println("추가된 뉴스 건 : " + updateCount); System.out.println("게시된 뉴스 건 : " + this.NewsCount); } }
NewsReader.java [구독자 구현 클레스] package pupustory.designpatterns.observer; public class NewsReader implements INewsReader{ private int NewsCount; private java.util.Date NewsUpdateTime; private java.text.SimpleDateFormat DateFormatter; INewsPaprCmpny NewsCompany = null; // INewsPaprCmpny type 을 받는 이유는 차후 구독을 해지할 경우를 위해 받습니다. public NewsReader(INewsPaprCmpny NewsCompany) { this.NewsCompany = NewsCompany; NewsUpdateTime = new java.util.Date(); DateFormatter = new java.text.SimpleDateFormat("yyyy/MM/DD HH:mm:ss.S"); NewsCount = 0; } // 뉴스정보가 갱신되었으므로 구독자도 갱신 합니다. public void updateNews(java.util.Date NewsUpdateTime, int NewsCount) { this.NewsUpdateTime = NewsUpdateTime; this.NewsCount = NewsCount; this.display(); } // 신문구독 해지 public void removeMe() { this.NewsCompany.removeReader(this); } public void display() { System.out.println( "[뉴스 구독자 코드] "+this.toString() + "\t[받은뉴스 수] " + this.NewsCount+ "\t[최종갱신 시간] " +this.DateFormatter.format(NewsUpdateTime)); } }
StartApp.java [실행 프로그램] package pupustory.designpatterns.observer; public class StartApp { public static void main(String args[]) { // 총 구독자는 10명 final int READER_COUNT = 10; // 신문사 객채 INewsPaprCmpny NewsCompany = new NewsPaprCmpny(); // 구독자 객체배열 INewsReader[] Readers = new NewsReader[READER_COUNT]; // 구독자 생성 for (int i=0; i<Readers.length;i++) { Readers[i] = new NewsReader(NewsCompany); } // 신문사에 구독자를 등록 합니다. NewsCompany.addReader(Readers); // 신문사에 신규 뉴스가 10건 추가 됨 NewsCompany.setNewsUpdate(10); // 5초간 Thread 대기 try { Thread.sleep(5000); } catch (Exception e) { e.printStackTrace(); } // 신문사에 신규 뉴스가 5건 추가 됨 NewsCompany.setNewsUpdate(5); } }

위 코드의 주석을 보면 대충 보기만 해도 감이 올 것이다.

먼저 우리는 interface INewsPaprCmpny (신문사)를 사용했다. 그리고 interface INewsReader (구독자)를 이용했다.

그것을 상속받은 클레스는 해당 메소드를 구현 했고,신문사의 뉴스가 추가발생하게 되면 setNewsUpdate() 메소드를 호출 한다.

메소드가 호출되면 'this.notifyReaders();' 구문이 실행되므로 구독하고 있는 모든이에게(ArrayList) 뉴스가 추가되었고,

구독자의 메소드에 뉴스 갯수와 날짜를 알려주므로 구독자는 그 정보를 갱신하게 된다. 그리고 그 결과를 display() 메소드로 출력 한다.

Q. 위와같은 코드로 작성한다면 변경이 있을때마다 모두에게 호출하게 된다.
   어떤 객체는 단1개의 값만 요구할 때가 있을 수 있다. 그런거라면 getter를 이용해 해당 객체가 알아서 가져오는건 어떨까?
A. 이것은 사용자가 임의로 경우에 맞게 사용할 수 있다. 바로 '푸시'와 '풀' 방식을 이용할 수 있기 때문이다.

간단히 설명하자면 푸시방식은 위의 방식대로 '신문사 -> 구독자에게 값을 밀어주는(푸시) 방식'이다.

주제의 값이 바뀌면 신문사는 메소드를 호출해 구독자에게 변경값을 통보해 준다.

하지만 모든 구독자가 이런 방식을 취하지 않아야 하는 경우도 있을수 있다. 예를 들어 신규뉴스건만 필요하고 갱신날짜는 필요 없을 경우도 있다.

바로 '신문사 -> 구독자에게 요청해 값을 가져가는(풀 방식) 방식'인 것이다.

이렇게 될 경우 단지 구독자 클레스는 신문사 클레스의 레퍼런스를 보유하고, 게터(getter)를 이용해 받아오는 방법을 적용하면 쉽게 될 것이다.

java에서는 친절하게도 이러한 옵저버 패턴을 손쉽게 사용할 수 있는 API를 제공한다.

바로 java.util패키지에 있는 Observer [interface]와 Observable [class]가 그것이다. 두가지를 살펴보면 ..

class Observable { addObserver(); deleteObserver(); notifyObservers(); // Observable 상태를 true(변경있음) 호출합니다. setChanged(); // Observable 상태를 false(변경없음, 혹은 변경을모두 적용 함)로 변경합니다. clearChanged(); // Observable 상태를 알려줍니다. hasChanged(); } interface Observer { // Observer의 정보를 갱신합니다. update(Observable o, Object arg) }

위에서 주목할 것은 setChanged() 메소드와 관련된 것 들이다. Obserable 소스를 살펴보면 알겠지만 내부적으로 변경여부에 대한 boolean changed 값이 존재하고, setChanged() 메소드를 통해 값을 'true'로 바꾼다. 이렇게 값이 바꾼 뒤  notifyObservers() 메소드를 진행하게 된다. 이때 if (!changed) 조건으로 조회를 하므로 반드시 setChanged()를 호출해야 하며, 호출 뒤 값은 자동으로 스위칭 된다. (스위칭을 강제로 하려면 clearChanged() 를 호출하고, changed값을 알고자 한다면 hasChanged()를 호출하면 된다. 기타 자세한 것은 javadoc 이용)

이제 java API를 이용해 코드를 작성하면 다음과 같다.

NewsPaprCmpny.java [신문사 클레스] package pupustory.designpatterns.observer.usejdk; public class NewsPaprCmpny extends java.util.Observable { private java.util.Date NewsUpdateTime = null; private int NewsCount; public NewsPaprCmpny() { NewsUpdateTime = new java.util.Date(); NewsCount = 0; } public void setNewsUpdate(int updateCount) { NewsCount += updateCount; NewsUpdateTime = new java.util.Date(); this.display(updateCount); this.setChanged(); // 풀 방식으로 구독자가 신문사에 객체를 받아 정보를 갱신 함 this.notifyObservers(); // 푸시 방식으로 갱신된 정보를 NewsInfoBean 에 담아 구독자에게 보냄 this.notifyObservers(new NewsInfoBean(NewsUpdateTime, NewsCount)); } public void display(int updateCount) { System.out.println("뉴스 배포사에서 새로운 뉴스를 추가했습니다 !!"); System.out.println("추가된 뉴스 건 : " + updateCount); System.out.println("게시된 뉴스 건 : " + this.NewsCount); } // 풀방식 구독자 getter public java.util.Date getNewsUpdateTime() { return NewsUpdateTime; } // 풀방식 구독자 getter public int getNewsCount() { return NewsCount; } }
NewsReader.java [구독자 클레스] package pupustory.designpatterns.observer.usejdk; import java.util.Observable; public class NewsReader implements java.util.Observer{ private int NewsCount; private java.util.Date NewsUpdateTime; private java.text.SimpleDateFormat DateFormatter; private Observable NewsCmpny; // 신문사 객체를 생성자에서 받음 public NewsReader(Observable O) { this.NewsCmpny = O; // 신문사에 구독 추가 함 NewsCmpny.addObserver(this); NewsUpdateTime = new java.util.Date(); DateFormatter = new java.text.SimpleDateFormat("yyyy/MM/DD HH:mm:ss.S"); NewsCount = 0; } public void display(String type) { System.out.println( "[뉴스 구독자 코드("+type+") ] "+this.toString() + "\t[받은뉴스 수] " + this.NewsCount+ "\t[최종갱신 시간] " +this.DateFormatter.format(NewsUpdateTime)); } public void update(Observable o, Object arg) { //풀방식으로 Observable 객체를 받아 구현된 NewsPaprCmpny 캐스팅 확인 if (o instanceof NewsPaprCmpny) { // NewsPaprCmpny 캐스팅 후 게터(getter) 를 이용해 값을 '풀'합니다. NewsPaprCmpny updateObserable = (NewsPaprCmpny)o; this.NewsUpdateTime = updateObserable.getNewsUpdateTime(); this.NewsCount = updateObserable.getNewsCount(); this.display("pull"); } // 푸시방식으로 arg 객체를 받아 NewsInfoBean 객체로 캐스팅 확인 if (arg instanceof NewsInfoBean) { // NewsInfoBean 캐스팅 후 변경돤 값이 들어 있는 bean 의 값으로 '푸시'합니다. NewsInfoBean bean = (NewsInfoBean)arg; this.NewsUpdateTime = bean.getNewsUpdateTime(); this.NewsCount = bean.getNewsCount(); this.display("push"); } } }
NewsInfoBean.java [신문정보 Bean] package pupustory.designpatterns.observer.usejdk; // 신문 정보 Bean public class NewsInfoBean { private java.util.Date NewsUpdateTime = null; private int NewsCount; public NewsInfoBean(java.util.Date date, int NewsCount) { this.NewsUpdateTime = date; this.NewsCount = NewsCount; } public java.util.Date getNewsUpdateTime() { return NewsUpdateTime; } public void setNewsUpdateTime(java.util.Date newsUpdateTime) { NewsUpdateTime = newsUpdateTime; } public int getNewsCount() { return NewsCount; } public void setNewsCount(int newsCount) { NewsCount = newsCount; } }
StartApp.java [실행 프로그램] package pupustory.designpatterns.observer.usejdk; import java.util.*; public class StartApp { public static void main(String args[]) { // 구독자 총 10명 final int READER_COUNT = 10; // 신문사 객체 NewsPaprCmpny NewsCompany = new NewsPaprCmpny(); // 구독자 배열 객체 Observer[] Readers = new NewsReader[READER_COUNT]; // 구독자 생성 for (int i=0; i<Readers.length;i++) { Readers[i] = new NewsReader(NewsCompany); // 구독자가 신문사에 구독을 신청 함 NewsCompany.addObserver(Readers[i]); } // 신문사에 신규 뉴스가 10건 추가 됨 NewsCompany.setNewsUpdate(10); // 5초간 기다림 try { Thread.sleep(5000); } catch (Exception e) { e.printStackTrace(); } // 신문사에 신규 뉴스가 5건 추가 됨 NewsCompany.setNewsUpdate(5); } }

중요한것은 바로 '풀'과 '푸시'방식의 선택이다. 위에선 주석처리 되었지만 구독자 클레스의 public void update(Observable o, Object arg)를 보면 알 수 있다.

이쯤되면 이미 알고 있겠지만 푸시 방식은 신문사가 값을 구독자에게 '떠먹여 주는'방식이다. 따라서 신문사가 푸시 방식을 적용하게 되면 notifyObservers(Object arg) 메소드를 호출하게 되는데,

 구독자 클레스의 public void update(Observable o, Object arg) 에서 arg로(신문사에서 NewsInfoBean로 넘겨 줌) 넘겨주게 되고, 구독자는 그것을 Object로 받아 케스팅 후 게터(getter)로 자신의 값을 변경 했다.
 
 즉, 신문사가 'bean에 담아서 정보를 너에게 줄테니 넌 그것을 받아서 자신의 값을 변경하도록 해!' 하는 방식인 것이다.
 
 풀 방식을 적용하게 되면 인자 없이 notifyObservers()를 호출하게 되는데 당연히 구독자의 void update(Observable o, Object arg) 중 arg는 null넘어가게 되고 o 객체에는 '신문사'객체가 넘어가게 된다.
 
 신문사 객체는 자신의 값을 가져올 수 있는 게터(getter)를 보유하고 있으니 구독자는 그것을 받아와 사용할 것이다.
 
 즉, 구독자가 '신문사가 자신의 객체를 넘겨주고, 그것에 게터(getter)가 있으니 그걸 받아서 내 값을 변경하면 되겠다!'는 방식인 것이다.

여기서 java.util.Observable의 단점은 다음과 같다.

1. Observable는 class이므로 내가 사용하는 class가 이미 상속받은 class가 있다면 사용할 수 없다.
(이것은 자바에서 말하는 class상속은 단 1개만 된다는 것으로 인해 발생 한다.
 또 Observable 인터페이스가 제공되지 않는다.)

2. Observable의 핵심 메소드는 외부에서 호출될 수 없다.
setChanged() 메소드가 protected로 선언되어 있으므로 상속관계 등의 관계가 아니라면 아예 접근할 수 없다.

위의 단점을 극복하기 위해선 애초에 상위 클레스에 Observable를 상속받아 작성한 후 그것을 다시 상속하는 방법이 있을 수 있다. 아니면 아예 처음에 만들었던 방식으로 직접 구현하는 방식 등의 여러 해결책이 있을 수 있다.

디자인 원칙

핵심정리

Pupustory Dev/Design Patterns