이전 기사(Singleton 패턴)을 쓰면서, 다음에 다루어야 할 주제는 Observer 패턴이 아니면, Factory Method 패턴이라고 생각했다. GUI의 구조를 보면 Observer 패턴을 설명할 때 재사용할 수 있을 것 같은 생각이 들었고, 패턴의 분류에 따르면 Singleton 패턴은 Creational 패턴에 속하고, 또한 그 간단한 패턴에서도 다른 패턴을 하나 사용하고 있는데, 그것이 Factory Method 패턴이다.

어느 패턴을 먼저 설명하더라도 약간의 준비 작업을 필요하다. Factory Method 패턴을 설명하려고 하면, Creational 패턴들이 전체적으로 다루고 있는 두가지 문제에 대한 설명이 필요하다. Creational 패턴을 사용하는 목적은 주로 두가지라고 할 수 있는데, 하나는 시스템이 사용하는 Concrete 클래스가 무엇인지 감추는 것이고, 또 다른 하나는 객체가 어떻게 생성되며, 구성되는지 감추는 것이다.[Note : Concrete 클래스란 직접적으로 객체 생성이 가능한 클래스를 말한다. 즉 인터페이스나 Abstract 클래스가 아닌 클래스이다.]

이 두가지가 주요한 목표라면, 어떻게 왜 그 목표를 설정하게 되었는지를 이해하면 Creational 패턴들에 대한 전반을 이해하고, 각 패턴들을 이해하는데 도움이 될 것이다.

이 기사에서는 GRASP Pattern을 설명할 것이다. GRASP 패턴은 General Responsibility Assignment Software Patterns의 축약어이다. Object-Oriented 디자인의 핵심 문제는 각 객체에 역할(또는 책임)을 부여하는 것이다. GRASP Pattern은 역할 부여의 원칙들을 말하고 있다. 일반적으로 디자인 패턴이라고 불리우는 것들처럼 구체적인 구조는 없지만, 각 디자인 패턴들은 GRASP 패턴이 제시하는 철학를 각 상황에서 구체적으로 구현할 것이라 볼 수 있다. GRASP 패턴을 설명하면, Creational 패턴들이 왜 앞에서 설명한 두 가지를 목표로 하고 있는지를 이해하는데 도움이 되리라 생각된다.

GRASP 패턴은 아홉 가지로 구성되어 있다. 사실 각 패턴들이 너무 간단해서 싱거울 정도이다.

1. Information Expert: 역할을 수행할 수 있는 정보를 가지고 있는 객체에 역할을 부여하자. 단순해 보이는 이 원칙은 객체지향의 기본 원리 중에 하나이다. 객체는 데이터와 처리로직이 함께 묶여 있는 것이고, 자신의 데이터를 감추고자 하면 오직 자기 자신의 처리 로직에서만 데이터를 처리하고, 외부에는 그 기능(역할)만을 제공해야 하기 때문이다.


2. Creator: 객체의 생성은 생성되는 객체의 컨텍스트를 알고 있는 다른 객체가 있다면, 컨텍스트를 알고 있는 객체에 부여하자. A 객체와 B 객체의 관계의 관계가 다음 중 하나라면 A의 생성을 B의 역할로 부여하라.
- B 객체가 A 객체를 포함하고 있다.
- B 객체가 A 객체의 정보를 기록하고 있다.
- A 객체가 B 객체의 일부이다.
- B 객체가 A 객체를 긴밀하게 사용하고 있다.
- B 객체가 A 객체의 생성에 필요한 정보를 가지고 있다.


3. Controller: 시스템 이벤트(사용자의 요청)를 처리할 객체를 만들자. 시스템, 서브시스템으로 들어오는 외부 요청을 처리하는 객체를 만들어 사용하라. 만약 어떤 서브시스템안에 있는 각 객체의 기능을 사용할 때, 직접적으로 각 객체에 접근하게 된다면 서브시스템과 외부간의 Coupling이 증가되고, 서브시스템의 어떤 객체를 수정할 경우, 외부에 주는 충격이 크게 된다. 서브시스템을 사용하는 입장에서 보면, 이 Controller 객체만 알고 있으면 되므로 사용하기 쉽다.


4. Low Coupling: 객체들간, 서브 시스템들간의 상호의존도가 낮게 역할을 부여하자. Object-Oriented 시스템은 각 객체들과 그들 간의 상호작용을 통하여 요구사항을 충족시키는 것을 기본으로 한다. 그러므로, 각 객체들 사이에 Coupling이 존재하지 않을 수는 없다. 이 패턴은 요구사항은 충족시키면서도 각 객체들, 각 서브시스템 간의 Coupling를 낮은 수준으로 유지하는 방향으로 디자인하라고 말하고 있다. Low Coupling은 각 객체, 서브시스템의 재 사용성을 높이고, 시스템 관리에 편하게 한다.


5. High Cohesion: 각 객체가 밀접하게 연관된 역할들만 가지도록 역할을 부여하자. 이 패턴은 Low Coupling 패턴과 동전의 양면을 이루는 것으로, 한 객체, 한 서브시스템이 자기 자신이 부여받은 역할만을 수행하도록 짜임새 있게 구성되어 있다면, 자신이 부여 받은 역할을 충족시키기 위해 다른 객체나 시스템을 참조하는 일이 적을 것이고, 그것이 곧 Low Coupling이기 때문이다.


6. Polymorphism: 객체의 종류에 따라 행동양식이 바뀐다면, Polymorphism 기능을 사용하자. Object-Oriented 시스템은 상속과 Polymorphism(다형성)을 지원한다. 만약 객체의 종류에 따라 행동이 바뀐다면 객체의 종류를 체크하는 조건문을 사용하지 말고, Object-Oriented 시스템의 Polymorphism 기능을 사용하라.


7. Pure Fabrication: Information Expert 패턴을 적용하면 Low Coupling과 High Cohesion의 원칙이 깨어진다면, 기능적인 역할을 별도로 한 곳으로 모으자. 데이터베이스 정보를 저장하거나, 로그 정보를 기록하는 역할에 대해 생각해 보자. 각 정보는 각각의 객체들이 가지고 있을 것이다. 이 때 Information Expert 패턴을 적용하면, 각 객체들이 정보를 저장하고, 로그를 기록하는 역할을 담당해야 하지만, 실제로 그렇게 사용하는 사람들은 없다. 이것은 그 기능들이 시스템 전반적으로 사용되고 있기 때문에 각 객체에 그 기능을 부여하는 것은 각 객체들이 특정 데이터베이스에 종속을 가져오거나, 로그을 기록하는 매커니즘을 수정할 경우, 모든 객체를 수정해야 하는 결과를 가져온다. 즉 Low Coupling의 원칙이 깨어지게 된다. 이럴 경우에는 공통적인 기능을 제공하는 역할을 한 곳으로 모아서 가상의 객체, 서브시스템을 만들어라.


8. Indirection: 두 객체 사이의 직접적인 Coupling을 피하고 싶으면, 그 사이에 다른 객체를 사용하라. 여기서 말하는 다른 객체란 인터페이스가 될 수 있고, 주로 인터페이스인 경우가 많다. 그런 특별한 경우는 아래에 설명된 Protected Variations 패턴이라고 부를 수 있다.


9. Protected Variations: 변경될 여지가 있는 곳에 안정된 인터페이스를 정의해서 사용하자. JDBC에 대해서 생각해 보자. JDBC는 일련의 인터페이스들로 구성되어 있으며, 각 데이터베이스 벤더들이 인터페이스를 구현한 Concrete 클래스를 제공하고 있다. 데이터베이스 기능을 사용하는 시스템의 입장에선 각 벤더들이 구현방식을 바꾸었을 때, 자신의 코드를 수정하고 싶지 않을 것이다. 그래서 Driver를 로딩하는 코드를 제외하고는 모두 인터페이스를 사용함으로서 데이터베이스의 변경시에도 Driver 로딩만 바꾸어 주면 되도록 데이터베이스 관련 작업이 필요한 곳에는 안정된 JDBC 인터페이스를 사용한 것이다.

지금까지 GRASP 패턴에 대해서 살펴보았다. 다시 처음 주제로 돌아와서, Creational Pattern에서 실제로 사용되는 Concrete 클래스를 숨기려고 하는 이유는 Low Coupling를 지원하려고 하기 때문이며, 변경될 여지가 있는 것들(Protected Variations)을 사용하는 시스템에 충격을 감소시키기 원하기 때문이다. Concrete 클래스를 숨겼지만, 결국 그 객체를 사용하기 해야 한다. 그러면 어떻게 사용할 것인가? 일반적으로 인터페이스 타입의 변수에 저장해서 사용한다. 각 Concrete 클래스를 대표하는 안정된 인터페이스를 만들 수 있다면, 그럴 경우에만 Creational Pattern들은 자신의 역량을 최대할 발휘할 수 있다. 두 번째로 왜 객체의 생성과 구성을 감추려고 하는가? 어떤 객체를 사용하기 위해서는 두 가지 작업이 필요하다. 먼저 객체를 생성해야 한다. 생성되어 있다면, 객체에 대한 Reference를 얻어와야 한다. 두 번째는 그 객체에 정의된, 사용하고자 하는 메소드을 알아야 한다. 객체 사용시 Low Coupling을 원한다면, 두 가지 작업을 해야 한다. 객체 생성을 숨기고, 메소드를 (주로 인터페이스를 이용하여) 자신이 원하는 수준으로 Abstract시킨다. Creational Pattern은 전자를 Structural Pattern들과 Behavioral Pattern들은 후자를 한다.

다음 기사에서는 Creational Pattern 중에 하나인 Factory Method 패턴을 살펴볼 것이다.

흠.. 어렵다..ㅠㅠ

다운로드

웹로직 8.1 릴리즈 노트
다운로드

웹로직 8.1 설치가이드
unix / windows

웹로직 8.1 개발 Tutorial 01 - Domain 및 Server 생성
다운로드

웹로직 8.1 개발 Tutorial 02 - DB(Point_Base) Start
다운로드

웹로직 8.1 개발 Tutorial 03 - 리소스 설정(JDBC,JMS등)
다운로드

웹로직 8.1 개발 Tutorial 04 - Development Mode로 사용하기
다운로드

웹로직 8.1 개발 Tutorial 05 - MedRec 프로젝트 디렉토리 생성
다운로드

웹로직 8.1 개발 Tutorial 06 - WebLogic Source 디렉토리 구조
다운로드

웹로직 8.1 개발 Tutorial 07 - Split Development Directory를 사용한 App 컴파일
다운로드

웹로직 8.1 개발 Tutorial 08 - Web Application의 DD
다운로드

웹로직 8.1 개발 Tutorial 09 - 개발환경에서 MedRec 디플로이
다운로드

웹로직 8.1 개발 Tutorial 10 - Web Services에 Stateless Session EJB 사용
다운로드

웹로직 8.1 개발 Tutorial 11 - Client에서 Web Services호출
다운로드

웹로직 8.1 개발 Tutorial 12 - MedRec 프로젝트의 컴파일
다운로드

웹로직 8.1 개발 Tutorial 13 - 분산 환경을 위한 MedRec의 패키징
다운로드

웹로직 8.1 개발 Tutorial 14 - Production환경으로 MedRec 패키지 Deploy
다운로드

웹로직 8.1 개발 Tutorial 15 - 어드민 콘솔을 이용한 애플리케이션관련 보안처리
다운로드

웹로직 8.1 개발 Tutorial 16 - 어드민 콘솔을 이용한 EJB 보안처리
다운로드

웹로직 8.1 개발 Tutorial 17 - 보안 처리를 위한 Copying과 Reinitializing
다운로드

웹로직 8.1 개발 Tutorial 18 - MedRec애플리케이션의 Re-Deploy
다운로드

웹로직 8.1 개발 Tutorial 19 - MedRec 애플리케이션의 클러스터링
다운로드

웹로직 8.1 JDBC 설정
다운로드

웹로직 8.1 DB Refresh(Oracle)
다운로드

웹로직 8.1 WebApplication 디플로이
다운로드

웹로직 8.1 JDBC Connection Pool의 monitoring
다운로드

한번에 싹~ 다받기
다운로드

startWebLogic.cmd 파일은 웹로직 서버를 실행하기 위한 배치파일로서 실행할때 반영되는 중요한 환경 변수 값이 있다. 여러 환경 변수중 PRODUCTION_MODE 값을 false 로 설정해야지만 서블릿이나 jsp가 수정되었을때 자동으로 수정된 값을 적용할 수 있게 된다.

PRODUCTION_MODE 값을 지정하지 않게 되면 서블릿이나 jsp가 변경되었을 경우 웹로직 서버를 재시작 할 경우에만 변경된 내용이 적용된다



개발시에는 이 값을 false 로 하고, 개발 완료시에는 이 값을 true로 지정...!!





@ECHO OFF

@REM WARNING: This file is created by the Configuration Wizard.
@REM Any changes to this script may be lost when adding extensions to this configuration.

SETLOCAL

@REM *************************************************************************
@REM This script is used to start WebLogic Server for the domain in the
@REM current working directory. This script simply sets the SERVER_NAME
@REM variable and starts server.
@REM
@REM To create your own start script for your domain, all you need to set is
@REM SERVER_NAME, then starts the server.
@REM
@REM Other variables that startWLS takes are:
@REM
@REM WLS_USER - cleartext user for server startup
@REM WLS_PW - cleartext password for server startup
@REM PRODUCTION_MODE - true for production mode servers, false for
@REM development mode
@REM JAVA_OPTIONS - Java command-line options for running the server. (These
@REM will be tagged on to the end of the JAVA_VM and MEM_ARGS)
@REM JAVA_VM - The java arg specifying the VM to run. (i.e. -server,
@REM -hotspot, etc.)
@REM MEM_ARGS - The variable to override the standard memory arguments
@REM passed to java
@REM
@REM For additional information, refer to the WebLogic Server Administration
@REM Console Online Help(http:\\e-docs.bea.com\wls\docs81\ConsoleHelp\startstop.html)
@REM *************************************************************************

@REM Initialize the common environment.

set WL_HOME=C:\bea\weblogic81
for %%i in ("%WL_HOME%") do set WL_HOME=%%~fsi





set PRODUCTION_MODE=false






set JAVA_VENDOR=Sun

set JAVA_HOME=C:\bea\jdk141_05
for %%i in ("%JAVA_HOME%") do set JAVA_HOME=%%~fsi

@REM Call commEnv here AFTER setting the java_vendor to get common environmental settings.

call "%WL_HOME%\common\bin\commEnv.cmd"

@REM Set SERVER_NAME to the name of the server you wish to start up.

set SERVER_NAME=myserver

set CLASSPATH=%WEBLOGIC_CLASSPATH%;%POINTBASE_CLASSPATH%;%JAVA_HOME%\jre\lib\rt.jar;%WL_HOME%\server\lib\webservices.jar;%CLASSPATH%

@REM Call WebLogic Server

echo .
echo CLASSPATH=%CLASSPATH%
echo .
echo PATH=%PATH%
echo .
echo ***************************************************
echo * To start WebLogic Server, use a username and *
echo * password assigned to an admin-level user. For *
echo * server administration, use the WebLogic Server *
echo * console at http:\\[hostname]:[port]\console *
echo ***************************************************

%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% -Dweblogic.Name=%SERVER_NAME% -Dweblogic.ProductionModeEnabled=%PRODUCTION_MODE% -Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy" weblogic.Server



ENDLOCAL

Singleton 패턴 - 한빛네트워크 에서 발췌합니다.
저자 : 김대곤


디자인 패턴은 매력적인 주제이다. 그리고 어려운 주제이다. 누구나 패턴을 공부하다보면,

반드시 만나게 되는 책이 있다. 이 책의 두 가지 문제점은 영어로 된 원서라는 것과 자바

예제를 제공하고 있지 않다는 점이다. 하지만 디자인 패턴을 설명한 책 중에서 아직도 가

장 널리 사용되어지고, 사랑받고 있다. 많은 사람들이 예상하듯이 이 책은 Gang of Four(

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)가 쓴 "Design Patterns:

Elements of Reusable Object-Oriented Software(1995), Addison-Wesley"이다.

내가 이 책을 처음 본 것이 몇 년 전이고, 그 이후에도 한 번 이상은 본 것 같은데.

아직도 이해하지 못하는 부분들이 많다. 특히 실제로 사용하지 않았던 패턴들의 설명은

보고 돌아서면 도무지 생각이 나지 않는다.


하지만, 지금은 몇몇 패턴들은 거의 외우고 있고, 문제에 부딪혔을 때 사용할 수 있을 정

도는 되었다. 아니 멋드러지게 변형해서 사용하기도 하고, 주로 몇 개의 패턴을 연결해서

사용한다. 나머지 패턴에 대해서 이해하려고 안달하지도 않고, 적어도 나에겐 쓸모없는

패턴이라고 생각하고 볼 생각도 하지 않는다. 아주 가끔 각 장의 처음 몇 줄을 읽어보긴

하지만. 이러한 현상은 패턴의 정의에서 보면 당연해 보인다. 정의에 따르면, 패턴은 "특

정한 컨텍스트에서 자주 발생하는 문제에 대한 해결책"이다. 특정한 컨텍스트을 만나지

않으면, 그 컨텍스트에 정의된 패턴은 알아야 될 필요가 없다. 그리고만나는 컨텍스트는

자주 만나기 때문에 항상 몇몇 패턴들만 사용한다. 내년에는 Visitor 패턴을 공부해야 할

것이다. 내년에는 컴파일러를 만들어 볼 생각하고 있다. Visitor 패턴은컴파일러를 만들

때 유용한 패턴이다.


짧은 경험과 패턴을 어려운 하는 주위 사람들을 볼 때 패턴이 어려운 주요 이유는 해결책

을 이해하지 못해서가 아니라 컨텍스트와 문제를이해하지 못해서 이다. 왜 패턴을 써야하

는지, 언제 패턴을 써야 하는지 모르는 것이다. 책을봐도 여전히 이해가 되지 않는 것은

패턴을 설명하고 있는 대부분의 자료들이 패턴을 모두디자인 단계에서 다루고 있기 때문

이다. 디자인 패턴이 디자인 단계에서 쓰이는 것은 분명하다. 문제는 패턴이 정의된 컨텍

스트와 해결하고자 하는 문제는 코드 단계에서 발생하는 것이고, 그것을 코드 단계 전에

해결하려고 하는 것이 디자인 패턴이기 때문이다. 결국 문제와컨텍스트는 디자인 단계에

서 보면 대단히 모호해 보이고, 문제 같아 보이지도 않는다는 것이다. 실제로 패턴을 적

용하면 디자인 클래스 다이어그램은 더욱 복잡해진다.


필자는 일련의 패턴에 관한 기사들을 쓸 생각이다. 코드 단계에서 패턴을 살펴보고, 패턴

을 쓰면 좋은 점은 무엇이고, 패턴을 언제 써야하는지를 보여주는 것을 목표로 해서, 필요

하다면 디자인 단계에서 해결책들이 어떻게 보이지는 살펴보자.

Singleton 패턴은 가장 간단하면서도, 가장 많이, GUI를 사용한다면 반드시 사용해야 하는


패턴이다. 다른 패턴에서도 자주 Singleton 패턴을 이용하기도 한다. 이 패턴이 왜 필요

한지, 언제 써야하는지 이해하기 어렵다면, Object에 대한 오해에서 비롯된 것이라 믿는다.


Object에 대한 오해

Object는 귀신과 같은 존재이다. "귀신 같다"는 것은 한 번 나타났다 사라지면, 언제 다시

볼 지 알 수 없는, 통제할 수 없는 미지의 세계 속으로 빠져버린다는 말이다. 그러나 많은

사람들은 자신이 원할 때 언제나 꺼내서 쓸 수 있는 지갑 속의 화폐처럼 생각하는 경향이

있다. 다음 예제는 Object를 생성하는 Frame(CreateObject)과 Object를 사용할 Frame(Obje

ctUser)를 나눈 것이다. 목표는 CreateObject에서 생성한 SimpleObject를 ObjectUser에서

보는(찾는) 것이다. 데이타베이스, Object Serialization 등 어떠한 방법을 써도 무방하다.



Object가 같다는 것은 Object가 가진 데이터, attributes가 같다는 뜻이 아니라, Hashcode가

같아야 한다. 아래의 화면에서 보이는 객체는 동일한 클래스의 객체이며, attribute에 같은

값을 가지고 있으나, CreateObject가 생성한 객체는 아니다. 만약 동일한 객체라면

hashcode 가 같을 것이다. 소스의 나머지 부분들은 GUI를 위한 것이고, 각 Frame이 가지고

있는 actionPerformed() 메소드만 보면 된다. 아래는 CreateObject.java의 actionPerformed()

메소드에 있는 소스코드이다. 직접 해결해 보기 바란다. 그러면 나머지는 그냥 이해되리라

믿는다.

  String name  = inputName.getText();

  String value = inputValue.getText();

  SimpleObject simple = new SimpleObject(name, value);

  tablePanel.update(simple);

[Download Source - 1] : 소스는 패키지를 사용하였음.


Global access 와 Only one instance of a class

Singleton 패턴을 쓰는 목적은 Global access와 하나의 객체만을 생성되도록 강제하는데 있다.

사실 이것은 동전의 양면과 같다. 정확한 표현은 아니지만, 하나의 객체만 있기 때문에

Global access가 가능하기 때문이다. 위의 문제에 대해 심각하게 고민해 봤다면, 이 문제를

해결하기 위해서 소스가 얼마나 더러워(복잡해)지는 알 수 있을 것이다. Singleton 패턴은 귀신

같은 Object를 지갑 속의 화폐로 만들어 준다. 주의할 점은 객체를 새로운 객체를 생성해서 찾을

수는 없다는 것이다. 예를 들면, java.util.Vector에 들어있는 객체를 찾을 때, 모든 attribute가

동일한 값을 가지는 새로운 객체(object)를 만들어서 Vector.contains(object)를 쓸 수 없다는

뜻이다. 새로운 객체를 만드는 순간 그 객체를 전 시스템에서 유일한 객체이고, java.util.Vector에

들어 있는 객체들 중에 하나는 아닌 것이다.

Solutions

Singleton 패턴이

적용된 클래스의 구조는 다음과 같다.



Singleton이 적용된 클래스는 세가지 구조를 갖는다. 첫번째는 자기 자신의 클래스 타입으로 선언된

static 변수를 가진다. 이것은 UML에서 자기 자신과 Association를 갖는 것으로 나타난다. 두 번째는

외부에서 Singleton 클래스의 객체를 생성하지 못하도록 생성자를 private으로 선언한다. 마지막으로

자기 자신의 객체를 반환하는 static method(getInstance())를 제공한다. 꼭 getInstance일 필요도

없고, instance일 필요도 없다. 단지 자기 자신의 객체(static 변수에 저장된 객체)를 반환하는

static method이면 된다. 나머지 구조들은 필요에 따라 만들기도 하고, 없어지기도 한다.


Design Pattern 원서에는 Singleton 패턴을 사용하는 세 가지 방법이 나온다. 위에 설명한 것이 가장

일반적인 방식이다. 두 번째는 static method 대신 instance-side method를 사용하는 것이다. 하지만,

instance-side method는 자바에서 지원하지 않는 것 같고, 다른 프로그램 언어인 Smalltalk에서

지원되는 것으로 알고 있다. 이런 방식을 사용하는 이유는 static를 사용하는 경우, 상속에 제약을

주기 때문이다. 세 번째 방식은 Registry를 사용하는 것으로 가장 유연한 방법이다.

그러나 Registry 역할을 하는 것이 있던가 만들어야 한다.




소스를 보면 알게 되겠지만, Singleton 클래스는 여섯 개 이상의 SimpleObject 객체는 저장하지

못하도록 구현되었다. 그래서 ObjectUser에서는 일곱 번째 이후에 생성된 클래스는 불러서 쓸

수가 없다. 여기서 SimpleObject 객체의 생성을 GUI에서 할 수 없도록 고치면 똑 같은 방식으로

사용자가 일곱 개 이상의 객체를 만드는 것을 제약 수 있다. 만약 이 때 SimpleObject 객체를

하나만 가질 수 있도록 하면, 실제로 SimpleObject가 Singleton이 적용되지 않은 클래스라

하더라도 Singleton처럼 사용할 수 있다. 이런 메카니즘에 Registry를 이용하는 세 번째 방식이다.

하여튼 Singleton 패턴이 시스템이 가질 수 있는 객체 수를 제한할 때, 하나가 아니라 하더라도

언제든지 사용할 수 있다.

[Download Source - 2]


왜 항상 사용되어지지 않는가?

그러면 이런 의문에 부딪히게 된다. "이렇게 중요하고 반드시 필요한 패턴이라면,

내가 아직도 모르고 있었나?" 필자 생각에는 두 가지 이유 때문이다. 하나는 마치 Singleton처럼

행동하는 것을 사용하고 있기 때문이고, 객체를 일종의 함수처럼 사용하기 때문이다.

Singleton처럼 행동하는 것은 데이터베이스를 의미한다. 데이터베이스는 거대한 Singleton이다.

같은 객체를 사용할 수 있도록 해 주진 않지만, 자기자신은 하나이고, 실제 객체는 다르지만,

마치 같은 객체를 사용하고 있는 듯 각 attribute의 값을 동일하게 유지할 수 있도록 한다.

한 객체가 생성되어, 그 값들을 데이터베이스에 저장하면, 필요할 때는 값들을 가지고 다시

객체를 만든다. 그러면 정보의 입장에서 보면 그 객체가 부활한 것이다.

객체를 함수처럼 사용하다는 의미를 살펴보자. 게시판의 리스트를 조회하는 객체를 보면,

그 객체가 하는 일은 데이터베이스 또는 파일에서 정보를 읽어서 화면에 보여주는 역할만

할 뿐이다. 그 객체가 정보를 저장하고 있지 않기 때문에 함수와 같은 역할을 한다는 것이다.

데이터베이스이든 파일이든 Persistence를 제공하는 매카니즘을 사용하지 않고 작은 시스템을

개발해 보면 Singleton 패턴을 이해하는데 도움이 될 것이다.


다른 용도

그렇다고 Singleton 패턴이 전혀 사용되어지지 않는 것은 아니다. 먼저, 성능 향상에 사용된다.

데이터베이스에서 정보를 읽어오는 일은 무거운 작업이다. 한 번 읽어서 계속 사용되는 정보는

데이터베이스에서 읽어서 Singleton 객체가 가지고 있으면 언제든지 누구든지 사용할 수 있다.

두 번째는 데이터베이스에 저장시 Key값을 가져오기 위해 사용된다. 처음에 Max값을 가지고

와서, Key값이 요청될 때마다 값을 증가시키면, Singleton은 오직 하나의 객체가 존재함으로

Key의 유일성이 보장된다.


결어

마치 Singleton패턴이 사양길에 접어든 것처럼 보일지 모르지만, 여전히 유효하고,

간단하면서도 강력한 패턴인 것은 분명하다.

개성있는 자바라...

문서보기

원서로 읽는거 보다 훨씬 이해가 빠른건 역시 내가 영어가 안되기 때문이겠지..ㅡ_ㅡ;;


PDF 문서 다운로드

나도 얼릉 영어 좀 잘해서 원서좀 봐야되는데..ㅠㅠ

PDF 문서 다운로드