[2.5 다양한 룩앤필 표준 지원]
하드웨어와 소프트웨어 플랫폼 간의 이식성을 지원하는 것은 시스템 설게에 매우 중요한 일이다. 이식성에서 걸림돌이 되는 한 가지는 룩앤필 표준의 다양성이다. 이 표준은 응용프로그램이 어떻게 화면에 표시되고 어떻게 사용자의 요청에 반응하는지에 대한 표준 지침을 정의한다. 모티프를 기반으로 한 응용프로그램들은, 다른 플랫폼에서 이에 상응하는 응용프로그램과 완전히 똑같은 룩앤필을 갖고 있지는 않는다. 하나 이상의 플랫폼에서 돌아가는 응용프로그램은 그 플랫폼에서 제공하는 고유한 사용자 인터페이스 스타일 지침을 따라야 한다.
런타임에도 룩앤필을 변경할 수 있는, 최고의 유연성을 지원하는 설계는 만드는 것이 목표이다.
[객체 생성의 추상화]
우리 눈에 보이고 Lexi의 사용자 인터페이스와 상호작용하는 것 모두가 글리프이다. 보이지 않는 행이나 열도 글리프이다. 버튼이나 스크롤바, 메뉴 등과 같이 사용자 인터페이스에서 어떤 요소들을 제어할 때 동작하는 글리프들을 “위젯(widget)”이라고 한다.
다양한 룩앤필을 구현하기 위해 두 가지 종류의 Glyph 클래스
1.위젯의 각 카테고리별로 Glyph 클래스를 상속받는 서브클래스 집합
2.각 추상 클래스를 상속하여 서로 다른 룩앤필을 구현하는 서브클래스 집합
서로 다른 룩앤필에 대한 위젯들을 구분할 필요가 있다. C++의 생성자를 이용해서는 이런 ㅂ아식의 구현이 불가능하다. 즉, 생성자에 어떤 특정 스타일의 버튼을 생성하도록 직접 코딩하게 되면 런타임 스타일을 선택할 수 없다. 모든 위젯의 생성자마다 새로운 플랫폼에 적합한 인스턴스를 생성하도록 변경해야 한다면, 새로운 이식 요청이 들어올 때마다 행해야 하는 유지보수는 정말 끔찍한 일이 될 것이다.
적당한 위젯을 생성하기 위해 맞춘 룩앤필을 결정하는 방법이 필요하다. 명시적인 생성자 호출도 피하고 싶을 뿐 아니라, 이와 동시에 전체 위젯을 쉽게 변경할 수 있어야 한다. 이 두 마리 토끼는 객체를 생성하는 과정 자체를 추상화함으로써 모두 잡을 수 있다.
[팩토리와 제품 클래스]
GUIFactory 클래스는 위젯을 만드는 데 필요한 공통의 인터페이스를 정의하는 추상 클래스이다.
통칭, 팩토리는 제품(product) 객체를 생성한다고 한다. 팩토리는 모티프, 프레젠테이션 매니저별 객체를 생성한다. 게다가 팩토리가 생성하는 제품들은 서로 관련되어 있다. 제품들은 같은 룩앤필을 위한 위젯이다.
그렇다면 어디서 GUIFactory 클래스의 인스턴스를 얻어야 할까? 이를 위해서라면 guiFactory 변수는 전역 변수가 되든지 잘 알려진 클래스의 정적 멤버가 될 수 있을 것이다. 이럴 때 쓰는 패턴이 바로 단일체이다. 한 클래스에서 만든 인스턴스가 오직 하나만 존재할 때 사용할 수 있는 패턴이 바로 단일체 패턴이기 때문이다. 중요한 것은 guiFactory 인스턴스의 초기화는 위젯을 생성하기 전에 이루어지는 것이지 어떤 룩앤필이 필요한지를 알았을 때 이루어지는 것이 아니라는 점이다. 즉, guiFactory 인스턴스는 첫 번째 위젯이 필요할 때 생성된다.
만약 룩앤필을 컴팡리 타임에 결정한다면, 프로그램의 시작부에 새로운 팩토리 인스턴스를 할당하는 단순 대입문을 둠으로써 guiFactory를 초기화하면 된다. 런타임 팩토리를 선택하는 좀더 세련된 방법도 있다. 예를 들어, 문자열과 팩토리 객체를 대응시키는 등록저장소, 즉 레지스트리(registry)를 두고 유지할 수 있다. 레지스트리를 이용하면 플랫폼에 종속된 팩토리를 응용프로그램에 링크할 필요가 없다. 새로운 팩토리가 등장하면 레지스트리에만 등록하면 된다.
[추상 팩토리 패턴]
추상 팩토리 패턴의 참가 객체는 팩토리와 제품이다. 이 패턴은 클래스의 인스턴스를 직접 만들지 않고서도 관련된 제품 객체의 군을 생성하는 방법을 정의한다. 어떤 특정 팩토리를 지정하여 이를 통해서 제품을 생성하게 하는 방법으로 원하는 제품을 선택한다. 팩토리의 인스턴스만 바꾸면 전체 제품군을 바꿀 수 있다. 추상 팩토리 패턴은 동일 계열의 제품군을 다룰 수 있다는 점에서 다른 생성 패턴과 다르다.
댓글