[카테고리:] lecture

추상팩토리 패턴의 본질적 의미는 하위클래스에서 필요한 인터페이스의 추상적 선언에 있다.추상클래스 자체는 동작에 있어 어떠한 직접적인 의미도 없지만 인터페이스의 원래 형태에 대한 틀을 정의한다는 점이 특징이다.

추상팩토리 패턴에서 구현되는 하위클래스인 구체적 클래스는, 상위 클래스의 인터페이스를 따르기 때문에 구현된 구체적 하위클래스를 직접 사용하는 다른 코드 내에서 선택제어문 등을 줄일 수 있다. 다만 smalltalk는 타입이 의미가 없는 언어이기 때문에 인터페이스 설계에서 부담이 적지만 CTT등의 타입을 필요로 하는 (typed) 언어의 경우는 인터페이스를 좀 더 엄격하게 설계해야 할 필요가 있다.

추상팩토리 패턴은 무언가 결과를 얻어내는 코드에 있어 it문 등의 불필요한 제어문의 사용을 줄여서 프로그램의 흐름을 좀 더 간결하게 정리할 수 있다는 데에 가장 큰 의미가 있다. 프로그램 내의 호직을 분기없이 단순화하는 과정은 결과적으로 유지보수까지의 고민으로 이어지게 된다.

추상팩토리 패턴의 구현과 사용은 크게 세가지로 나눌 수 있다.
– Constant Method 방법
– 부품 카탈로그 방법
– 단일 팩토리 클래스 방법

각 방법에 대해 간단히 알아보도록 하자.

Constant Method
Constant Method 방법은 추상클래스 (상위클래스)에 하위클래스 호출시 사용 될 메서드의 구현을 공통된 코드로 구현하고, 하위클래스 에서는 공통된 코드에서 호출되는 내용을 개별적으로 직접 구현함으로서 추상계층을 한번 더 내부적으로 구현해서 유지보수를 편하게 한다는 차이점이 있다. 내부적으로 Public 메서드가 Private 메서드를 도출해서 Public 메서드를 통해 반환값을 처리하게 하는 논리 순서를 구현하는 방법이다. 이 방법은 분류별로 메서드를 만들어야 하며, 분류가 추가되는 경우 상위클래스 및 하위클래스에 추가되는 분류에 따른 메서드를 모두 작업해 주어야 한다.

부품 카달로그
부품 카달로그 방법은 상위클래스 및 하위클래스군에 반환값의 분류별로 메서드를 각각 만드는 것이 아니라, 하나의 메서드와 메서드의 인자에 따른 반환값의 정보를 가지고 있는 카탈로그를 구체적 하위 클래스의 내부에서 각각 유지함으로서 구조를 보다 단순하게 만든다. 이 방법은 반환값 및 인자의 분류가 추가되어도 구조의 큰 수정 없이 카달로그의 값만 조정함으로서 프로그램을 보다 쉽게 확장할 수 있다는 장점이 있다. factory를 사용하는 사용하는 코드에서는 동일한 인자를 넣어도 factory 객체가 창조하는 구체적 하위클래스에 따라 각각 다른 반환값을 얻게 된다.

Constant method 방법은 원하는 분류에 따라 각각 다른 메서드를 사용해야 하지만 부품 카달로그 방법은 동일 메서드에 인자만 다르게 하면 된다는 차이점이 있다. 그리고 추상 상위클래스에서 인자에 따른 값을 반환하는 메서드의 동작까지 선언하면 구체적 하위클래스에는 각 클래스의 카달로그 내용만 별도로 유지하면 되는 구조를 가지게 된다.

단일 팩토리 클래스 방법
단일 팩토리 클래스 방법은 별도의 하위클래스를 선언하지 않고 추상 클래스를 취급하던 상위 클래스에 연산을 필요로 하는 메서드와 연산의 대응값을 가지고 있는 값의 카달로그를 모두 포함시키는 방법이다. 하위클래스의 인스턴스를 사용하는것이 아니라 단일 클래스의 인스턴스를 생성할 때 별도의 메서드를 이용해서 원하는 결과 집합을 반환하는 인스턴스를 바로 생성해서 사용하는 방법이 된다. 이 경우 factory를 사용하는 코드에 변화는 없다. 단일 클래스는 클래스 메서드로 인자를 필요로 하지 않는 각 집합별 메서드를 가지게 된다.

var := factory Class initMethod

위의 구문을 통해 initMethod 에 해당하는 카달로그를 가지고 있는 var 객체를 가질 수 있으며 이 객체를 통해 원하는 값을 얻을 수 있게 된다.

ENIAC 을 기억하는가? computer의 역사를 보면 항상 등장하는 computer이며 그만큼 친숙한 기계이기도 하다. 진공관으로 만들어져 있으며 Bug 라는 용어가 만들어지게 한 장본인 이기도 하다. 이 컴퓨터는 제 2차대전 때 암호문을 해독하는데 사용되었다는 얘기로 유명하며 크기 역시 유명하다. 이렇게 사용된 진공관은 이후 트랜지스터와 IC로 발전되어 소형화되었고, 보다 고성능을 가지게 되었다. 지금 우리가 사용하는 computer의 원형이 되는 셈이다. 이렇게 초기의 진공관 컴퓨터들이 현재 사용하는 computer의 원형이 되었다면 분명 사용을 위해 programming을 했을텐데, 어떤 방법으로 프로그래밍을 했을까?

천공카드 – 또는 punch Card- 라는 조금 굵은 용지에 구멍을 뚫어서 그걸 ENIAC에 입력하는 방식을 사용했다.

그 당시는 지금처럼 I/O device (키보드나 모니터) 가 발달하지 않았던 시점이기 때문에 그나마 생각할 수 있었던 방식이 천공카드였다. 구멍을 실수로 잘못 뚫는다면 당연히 프로그래밍은 처음부터 다시 진행되어야만 했다. 물론 프로그램 뿐만이 아니라 프로그램에서 처리하게 될 data도 천공카드로 입력했다. 당연히 지금의 방식에 비해 비효율적이던 방법이지만 역사의 초창기는 늘 이렇기 때문이니 그 사람들을 탓하지는 마시기를.

이후 TR(트랜지스터)과 IC(집적회로)의 발달에 힘입어 전자제품업계는 눈부시게 발전했고 그것은 computer업계에도 영향을 미치기 시작했다. 키보드와 모니터가 만들어졌고 이는 computer에서 중요한 장치가 되었다. 그리고 대부분의 분야가 그렇듯이 초기의 컴퓨터는 대학에서 연구용으로 도입되었다.지금처럼 PC의 형태가 아닌 Host-Torminal 의 형태였다. 중앙 전산실에서 Host 서버가 관리되며 접근이 가능한 곳에 Serial 또는 interface를 사용한 Terminal 단말기들이 설치되는 형태였다. 지금은 없어진 “Digital” 이라는 회사의 “PDP”시리즈는 단연 중심이 있었다.

처음의 Programing은 어셈블러였다. 기계어와 거의 1:1의 대응이 되는 어셈블러는 제대로 된 프로그래밍의 초기격이라 할 수 있었다. 이후 Dennis MacAlistair Ritchie 와 Ken Thompson 에 의해 C언어가 만들어졌다. 해커들은 열광했다. C 언어는 강력하며 기계어보다 사용하기에 훨씬 쉬웠다. Berkely 에서는 UNIX를 C를 이용해서 만들기 시작했다. Generc OS 의 시대가 오기 시작했고 C언어의 시대가 오기 시작했다. 효율성을 보다 중시한 프로그래밍이 요구되었으며 당시 컴퓨터의 성능을 생각하면 이는 당연한 상황이었다. 구동에 시간이 오래 걸리는 프로그램을 좋아하는 사람은 없었기 때문이다.

이렇게 Enterprise 환경이 발달하는 동안…(진행중)

객체지향은 Software Modeling 의 방향을 인간에서 찾는다. 인간의 인식과 물리를 넘는 논리적 개념으로 현상을 분석하고 설명하며 구현한다. 또한 논리적 사고의 영역에서 설계적 효율성과 구현의 문제를 고민하는 분야이기도 하다.

Computer Science 에서 Design Pattern은 단기간에 등장한 것이 아니다.

고수들의 수많은 코딩과 경험에서 공통점을 찾고, 그것을 다듬어 Pattern화를 시키고, 분류 기준을 만들어서 정리한것이 Design Pattern 이다. 물론 우리가 알 지 못하는 더 많은 Pattern 이 존재하며 그런것들은 지금도 연구되어 새로이 논문이 되어 나타난다. 이렇게 효율성에 대해 정제된 결과가 바로 Design Pattern이다.

객체지향은 문명이 발전되어 온 것 처럼 지금도 발전되고 있다. 꾸준히 효율성과 편의성을 찾으며 멈추는 일 또한 없다. 이런 과정에서 Design Pattern이 중요해지는 것은 어찌보면 당연한 일이다. 발전을 위해서는 과거의 복기가 필요하며 과거의 기록에서 Pattern을 찾아내서 정리하고 다듬는 Design Pattern 은 객체지향 프로그램을 좀 더 좋은것으로 유지하기위한 필요요소 일 수 밖에 없다고 생각한다. 정리된 Pattern은 새로운 기능이나 library(Linked List의 구현체등)형태로 나타나는 경우가 있다. 이 때 관련된 이론을 잘 알아둔다면 이러한 것들을 사용하는 데에도 더 도움이 될 것이 아닐까?