Singleton 패턴을 아주 단순하게 설명하자면 단일 클래스에 대한 단일 인스턴스라고 할 수 있다. 하지만 정확하게 따지자면 Singleton은 “단일 인터페이스를 통한 단일 인스턴스의 관리”가 된다. Singleton이 구현된 환경이 단 한개의 class만이 존재하는것이 아니라 이 클래스를 상속받은 하위클래스가 존재하는 경우, 이 class 군에서 관리하는 인스턴스가 오직 하나만 존재하는것이 이 패턴의 핵심이라 할 수 있다. 상위클래스와 하위클래스가 존재하는 구조라고 해도 이 클래스 군에서는 하나의 인스턴스만 관리한다는 것이 Singleton 패턴이다. 이런경우 Singleton패턴을 환경변수 또는 현재 프로그램이 구동되는 환경에 따라 필요한 하위 클래스를 선택해서, 이를 단일 인스턴스로 관리하거나 필요한 동작 방식을 선택하게 된다.

Singleton의 하위클래스 까지 가지고 있는 구조의 경우 환경에 따라 어떤 레벨의 (또는 어떤 종류의) 하위 클래스를 사용하게 될지 등을 Singleton의 최상위 추상클래스의 initialize 초기화 메서드에서 선언해주면 이후 환경에 따라 자동으로 필요한 인스턴스를 생성하는 클래스를 설계할 수 있다.

Smalltalk 에서는 메타클래스가 Singleton의 예가 된다.

Prototype 은 패턴을 Prototype으로 설계된 클래스의 부사에 대한 내용이다. 좀 뜬금없는 예가 되겠지만 Lazarus 를 예로 들어보자. (Lazarus는 Open Source 프로젝트이며 fpc (free passal compileer)를 이용하는 RAD 틀이다.)

Lazarus의 실행화면에서 새 프로젝트를 생성하고 상단의 팔레트를 보자. 이 팔레트에서 button을 하나 드래그해서 Form 위에 놓아보자. 쉽게 확인할 수 있듯이 button 이 하나 놓여졌다. Prototype 패턴은 이를 위한 패턴이다. 간단한 개념이지 않은가?

팔레트는 Client 가린다. 팔레트의 역할은 button의 Prototype의 Tbutton 클래스로 부터 인스턴스를 만들어 Form의 아래쪽으로 넣는 역할을 한다. 지금의 설명처럼 Tbutton 클래스는 button 인스턴스의 Prototype이 된다. (사실은 Tbutton의 인스턴스를 복사해서 인스턴스를 만드는게 더 정확한 개념이지만 지금은 설명을 위해 넘어가자)

Form 위에 여러개의 button을 넣는 경우 button의 label property는 자동으로 바뀌어 생성된다. 이렇게 복사되는 인스턴스의 상태(status)를 변경하는 데에는 팔레트에서의 변경과 놓이는 form 에서의 변경 등 두가지 정도의 경우가 있다. 이 두가지 경우에 있어서 인스턴스에 대한 초기화 매서드에서 변경을 처리하는 경우와, 놓이는 form 에서 호출하게 되는 인스턴스의 메서드에 인자를 전달해서 변경을 만들어내는 방식이 고려될 수 있다.

클래스에 객체의 인스턴스를 생성해 내기위한 인터페이스 (메서드)를 정의하지만 어떤 클래스의 인스턴스를 생성할지에 대한 걱정은 추상클래스의 하위클래스에서 결정하는 패턴이다. 추상클래스에는 virtual 인터페이스만 있고 구현은 하위클래스(구체클래스)에서 이루어지며 인스턴스의 원래 클래스도 구현부에서 결정하게 된다.

(* Smalltalk에서는 어떻게 추상클래스와 구체클래스를 구분해서 정의하는가 – 조사필요)

ex)word와 excel의 “새문서 생성”등의 경우를 생각해보자.

둘 다 동일한 메서드를 쓸 수 있다.

Document Class >> create Document Object

다만 메서드 전송 후에 반환되는 인스턴스의 종류는 틀리다. 이런 경우를 위해서 사용된다.