앞글의 예외처리의 예외에서 소개한 코드는 아키텍쳐 레벨에서 보면 Pipes and Filter 패턴의 한 예이며 가장 많이 알려진 PAF 패턴의 예는 유닉스의 명령어이다. 유닉스의 모든 명령어는 char*가 입출력의 표준 메시지 포맷이기 때문에 ls -al | grep 'abc' | vi 식의 사용이 가능하다. 그리고 티스토리의 플러그인 방식도 PAF의 일례라고 볼 수 있다. 앞의 두 예 모두 순서에 상관없지만 PAF가 항상 순서에 관계없이 동작하는 것은 아니다.


PAF 패턴은 아래와 같은 특징이 있다.

1. 미래에 시스템의 기능을 향상시키기 위해서는 (심지어 사용자도) 프로세싱 단계를 변경하거나 혹은 재조합할 수 있어야 한다.
2. 작은 프로세싱 단계들은 서로 다른 상황에서 거대한 컴포넌트보다 쉽게 재사용된다.
3. 인접하지 않은 프로세싱 단계들 간에는 정보를 공유하지 않는다.
4. 입력데이타는 각기 다른 소스에서 얻는다.
5. 여러가지 방법으로 결과를 표시하거나 저장 할수 있어야 한다.
6. 단계를 멀티프로세싱 방식으로 처리하는 것도 수용할 수 있다. 예를 들어 병렬 혹은 준 병렬 방식을 체택할 수 있다.


절차는 아래의 단계를 밟는다.
1. 시스템의 테스크를 일련의 프로세싱 단계에 따라 구분한다.
2. 각 파이프 사이로 전달할 수 있도록 데이터 포맷을 정의한다.
3. 각 파이프를 어떻게 연결할지 결정한다. (Push? Pull?)
4. 필터를 설계하고 구현한다.
5. 오류 핸들링을 설계한다.
필요할 경우 단계의 중간에 파일에 추가적인 정보를 남기는 것도 고려할 수 있다.


PAF는 아래와 같은 장단점이 있다.

장점

1. 필터 교환에 유연하다.
2. 재조합에 유연하다.
3. 필터 컴포넌트를 재 사용할 수 있다.
4. 파이프라인의 프로토 타입을 빠르게 만들 수 있다.
5. 병렬 프로세싱의 효율성

단점

1. 상태정보를 공유하게 되면 비용이 많이 들며 유연성을 저하시키는 요인이 된다.
2. 병렬 프로세싱을 사용해 효율성을 얻을 것이라는 기대는 그저 망상일 뿐인 경우가 종종있다.
3. 데이타 변환에 과부하가 발생한다.
4. 오류 핸들링을 구현하기 힘들다.


 

'Framework > 아키텍쳐 일반' 카테고리의 다른 글

프로그래밍 패러다임  (0) 2009.03.12
아키텍쳐 패턴 - Broker 패턴  (0) 2009.03.12
아키텍쳐 패턴 - Layer 패턴  (0) 2009.03.11
Class Design  (0) 2009.03.07
나쁜 디자인의 징후  (0) 2009.02.22
Posted by bleujin