더 나은 개발 템플릿 구성을 위한 5가지 PHP 디자인 패턴

저자：Eve Cole 업데이트 시간：2009-06-01 18:19:49

디자인 패턴은 Java 설계자를 위한 것입니다. 적어도 여러분은 항상 그렇게 생각했을 것입니다. 사실 디자인 패턴은 누구에게나 유용합니다. 이러한 도구가 "건축 우주비행사"의 전유물이 아니라면 그것은 무엇입니까? PHP 애플리케이션에 왜 유용한가요? 이 문서에서는 이러한 문제에 대해 설명합니다.

Design Patterns라는 책은 소프트웨어 커뮤니티에 디자인 패턴을 소개했습니다. 이 책의 저자는 Erich Gamma, Richard Helm, Ralph Johnson 및 John Vlissides Design(일반적으로 "Gang of Four"로 알려짐)입니다. 제시된 디자인 패턴의 핵심 개념은 매우 간단합니다. 수년간 소프트웨어 개발을 연습한 후 Gamma와 다른 사람들은 건축가가 집과 건물을 디자인하고 욕실이 있어야 할 위치나 주방을 어떻게 구성해야 하는지에 대한 템플릿을 개발하는 것과 마찬가지로 고정된 디자인의 특정 패턴을 발견했습니다. 이러한 템플릿 또는 디자인 패턴을 사용한다는 것은 더 나은 건물을 더 빠르게 디자인한다는 것을 의미합니다. 소프트웨어에도 동일한 개념이 적용됩니다.

디자인 패턴은 강력한 소프트웨어를 더 빠르게 개발하는 데 유용한 방법을 나타낼 뿐만 아니라 대규모 아이디어를 친숙한 용어로 캡슐화하는 방법도 제공합니다. 예를 들어, 느슨한 결합을 제공하는 메시징 시스템을 작성 중이거나 Observer라는 패턴을 작성 중이라고 말할 수 있습니다.

더 작은 예제로 패턴의 가치를 입증하는 것은 매우 어렵습니다. 패턴은 실제로 대규모 코드 기반에서 작동하기 때문에 이는 종종 과잉처럼 느껴집니다. 이 문서에서는 대규모 애플리케이션을 보여주지 않으므로 이 문서에서 설명하는 코드 자체가 아닌 자신의 대규모 애플리케이션에 예제의 원칙을 적용하는 방법에 대해 생각해야 합니다. 이는 소규모 애플리케이션에서 패턴을 사용해서는 안 된다는 의미는 아닙니다. 많은 좋은 응용 프로그램은 작은 응용 프로그램으로 시작하여 큰 응용 프로그램으로 진행되므로 이러한 유형의 견고한 코딩 방식을 기반으로 구축하지 않을 이유가 없습니다. 이제 디자인 패턴과 이것이 왜 유용한지 이해했으므로 PHP V5에서 일반적으로 사용되는 5가지 패턴을 살펴보겠습니다.

팩토리 패턴

원래 Design Patterns 책에는 많은 디자인 패턴이 느슨한 결합 사용을 권장합니다. 이 개념을 이해하려면 많은 개발자가 대규모 시스템에서 작업하면서 겪는 힘든 여정에 대해 이야기하는 것이 가장 좋습니다. 코드 중 하나를 변경하면 문제가 발생할 수 있으며 시스템의 다른 부분(한때 전혀 관련이 없다고 생각했던 부분)에서 계단식 중단이 발생할 수 있습니다.

문제는 긴밀한 결합입니다. 시스템의 한 부분에 있는 함수와 클래스는 시스템의 다른 부분에 있는 함수와 클래스의 동작과 구조에 크게 의존합니다. 이러한 클래스가 서로 통신할 수 있도록 하는 패턴 세트가 필요하지만 연동을 피하기 위해 클래스를 단단히 묶고 싶지는 않습니다. 대규모 시스템에서는 많은 코드가 몇 가지 주요 클래스에 의존합니다. 이러한 클래스를 변경해야 할 때 어려움이 발생할 수 있습니다. 예를 들어 파일에서 읽는 User 클래스가 있다고 가정합니다. 데이터베이스에서 읽는 다른 클래스로 변경하려고 하지만 모든 코드는 파일에서 읽는 원래 클래스를 참조합니다. 이때는 공장모드를 이용하시면 매우 편리합니다.

팩토리 패턴은 객체를 생성하는 특정 메서드가 있는 클래스입니다. new를 직접 사용하지 않고도 팩토리 클래스를 사용하여 객체를 생성할 수 있습니다. 이렇게 하면 생성된 객체의 유형을 변경하려면 팩토리만 변경하면 됩니다. 이 팩토리를 사용하는 모든 코드는 자동으로 변경됩니다.

목록 1은 팩토리 클래스의 예를 보여줍니다. 방정식의 서버 측은 피드백을 추가하고, 피드백 목록을 요청하고, 특정 피드백과 관련된 기사를 얻을 수 있는 데이터베이스와 PHP 페이지 세트라는 두 부분으로 구성됩니다.

목록 1. Factory1.php

<?php
인터페이스 IUser
{
함수 getName();
}

User 클래스는 IUser를 구현합니다.
{
공개 함수 __construct( $id ) { }

공개 함수 getName()
{
"잭"을 반환합니다.
}
}

클래스 UserFactory
{
공개 정적 함수 만들기($id)
{
새로운 사용자 반환( $id );
}
}

$uo = UserFactory::Create( 1 );
echo( $uo->getName()."n" );
?>

IUser 인터페이스는 사용자 개체가 수행해야 하는 작업을 정의합니다. IUser의 구현을 User라고 하며 UserFactory 팩토리 클래스는 IUser 객체를 생성합니다. 이 관계는 그림 1의 UML로 표현될 수 있습니다.

그림 1. 팩토리 클래스와 관련 IUser 인터페이스 및 사용자 클래스

PHP 인터프리터를 사용하여 명령줄에서 이 코드를 실행하면 다음과 같은 결과를 얻을 수 있습니다.

%phpfactory1.php
잭
%

테스트 코드는 팩토리에서 User 개체를 요청하고 getName 메서드의 결과를 출력합니다.

팩토리 메소드를 사용하는 팩토리 패턴의 변형이 있습니다. 클래스의 이러한 공용 정적 메서드는 해당 유형의 개체를 구성합니다. 이 방법은 이 유형의 객체를 생성하는 것이 중요한 경우 유용합니다. 예를 들어, 객체를 생성한 다음 여러 속성을 설정해야 한다고 가정해 보겠습니다. 이 버전의 팩토리 패턴은 프로세스를 단일 위치에 캡슐화하므로 복잡한 초기화 코드를 복사하여 코드 베이스 전체에 붙여넣을 필요가 없습니다. Listing 2는 팩토리 메소드를 사용하는 예를 보여준다.

목록 2. Factory2.php

<?php
인터페이스 IUser
{
함수 getName();
}

User 클래스는 IUser를 구현합니다.
{
공개 정적 함수 로드($id)
{
새로운 사용자 반환( $id );
}

공개 정적 함수 생성( )
{
새로운 사용자 반환( null );
}

공개 함수 __construct( $id ) { }

공개 함수 getName()
{
"잭"을 반환합니다.
}
}

$uo = 사용자::로드( 1 );
echo( $uo->getName()."n" );
?>

이 코드는 훨씬 간단합니다. 여기에는 인터페이스 IUser와 이 인터페이스를 구현하는 User 클래스가 하나만 있습니다. User 클래스에는 객체를 생성하기 위한 두 가지 정적 메서드가 있습니다. 이 관계는 그림 2의 UML로 표현될 수 있습니다.

그림 2. 팩토리 메소드를 사용하는 IUser 인터페이스 및 사용자 클래스

명령줄에서 스크립트를 실행하면 다음과 같이 목록 1과 동일한 결과가 생성됩니다.

%phpfactory2.php
잭
%

위에서 언급한 것처럼 때로는 이러한 모드가 소규모 환경에서 과도하게 보일 수 있습니다. 그러나 모든 규모의 프로젝트에 적용할 수 있는 견고한 형태의 코딩을 배우는 것이 가장 좋습니다.

단일 요소 모드

이 유형의 리소스는 하나만 있기 때문에 일부 응용 프로그램 리소스는 배타적입니다. 예를 들어, 데이터베이스 핸들을 통한 데이터베이스 연결은 배타적입니다. 연결을 열거나 닫을 때 오버헤드가 발생하기 때문에 애플리케이션 전체에서 데이터베이스 핸들을 공유하려고 합니다. 단일 페이지를 가져오는 프로세스 중에는 더욱 그렇습니다.

단일 요소 모드는 이 요구 사항을 충족합니다. 애플리케이션에 한 번에 하나의 개체만 포함되어 있으면 이 개체는 싱글톤입니다. 목록 3의 코드는 PHP V5의 데이터베이스 연결 단일 요소를 보여줍니다.

목록 3. Singleton.php

<?php
require_once("DB.php");

클래스 DatabaseConnection
{
공개 정적 함수 get()
{
정적 $db = null;
if ( $db == null )
$db = 새로운 DatabaseConnection();
$db를 반환합니다.
}

개인 $_handle = null;
개인 함수 __construct()
{
$dsn = 'mysql://root:password@localhost/photos';
$this->_handle =& DB::Connect( $dsn, array() );
}

공개 함수 핸들()
{
$this->_handle을 반환합니다.
}
}

print( "Handle = ".DatabaseConnection::get()->handle()."n" );
print( "Handle = ".DatabaseConnection::get()->handle()."n" );
?>

이 코드는 DatabaseConnection이라는 단일 클래스를 보여줍니다. 생성자가 비공개이므로 자체 DatabaseConnection을 만들 수 없습니다. 그러나 정적 get 메서드를 사용하면 하나의 DatabaseConnection 개체만 가져올 수 있습니다. 이 코드의 UML은 그림 3에 나와 있습니다.

그림 3. 데이터베이스 연결 단일 요소

가장 좋은 증거는 핸들 메소드에 의해 반환된 데이터베이스 핸들이 두 호출 간에 동일하다는 것입니다. 이를 관찰하려면 명령줄에서 코드를 실행하면 됩니다.

% PHP 싱글톤.php
핸들 = 개체 ID #3
핸들 = 개체 ID #3
%

반환된 두 핸들은 동일한 개체입니다. 애플리케이션 전체에서 데이터베이스 연결 단일 요소를 사용하는 경우 동일한 핸들을 어디에서나 재사용할 수 있습니다.

전역 변수를 사용하여 데이터베이스 핸들을 저장할 수 있지만 이 접근 방식은 소규모 애플리케이션에만 적합합니다. 대규모 애플리케이션에서는 전역 변수 사용을 피하고 개체와 메서드를 사용하여 리소스에 액세스합니다.

관찰자 패턴

관찰자 패턴은 구성 요소 간의 긴밀한 결합을 방지하는 또 다른 방법을 제공합니다. 패턴은 매우 간단합니다. 객체는 다른 객체인 관찰자가 자신을 등록할 수 있도록 허용하는 메서드를 추가하여 객체 자체를 관찰 가능하게 만듭니다. 관찰 가능한 객체가 변경되면 등록된 관찰자에게 메시지를 보냅니다. 이러한 관찰자는 이 정보를 사용하여 관찰 가능한 객체와 독립적인 작업을 수행합니다. 결과적으로 객체는 이유를 이해하지 않고도 서로 대화할 수 있습니다. 간단한 예는 시스템의 사용자 목록입니다. 목록 4의 코드는 사용자 목록을 표시하고 사용자가 추가되면 메시지를 보냅니다. 이 목록은 사용자가 추가되면 메시지를 보내는 로그 관찰자를 통해 관찰할 수 있습니다.

목록 4. Observer.php

<?php
인터페이스 IObserver
{
함수 onChanged( $sender, $args );
}

인터페이스 IObservable
{
함수 addObserver( $observer );
}

UserList 클래스는 IObservable을 구현합니다.
{
개인 $_observers = 배열();

공개 함수 addCustomer( $name )
{
foreach( $this->_observers를 $obs로)
$obs->onChanged( $this, $name );
}

공개 함수 addObserver( $observer )
{
$this->_observers []= $observer;
}
}

UserListLogger 클래스는 IObserver를 구현합니다.
{
공개 함수 onChanged( $sender, $args )
{
echo( "'$args'가 사용자 목록에 추가되었습니다n" );
}
}

$ul = 새로운 UserList();
$ul->addObserver( new UserListLogger() );
$ul->addCustomer( "잭" );
?>

이 코드는 4개의 요소(인터페이스 2개와 클래스 2개)를 정의합니다. IObservable 인터페이스는 관찰할 수 있는 개체를 정의하고 UserList는 자신을 관찰 가능으로 등록하기 위해 이 인터페이스를 구현합니다. IObserver 목록은 관찰자가 되는 방법을 정의합니다. UserListLogger는 IObserver 인터페이스를 구현합니다. 이러한 요소는 그림 4의 UML에 표시되어 있습니다.

그림 4. 관찰 가능한 사용자 목록 및 사용자 목록 이벤트 로거

명령줄에서 실행하면 다음과 같은 출력이 표시됩니다.

% PHP 관찰자.php
사용자 목록에 'Jack'이 추가되었습니다.
%

테스트 코드는 UserList를 생성하고 여기에 UserListLogger 관찰자를 추가합니다. 그런 다음 소비자를 추가하고 UserListLogger에 이 변경 사항을 알립니다.

UserList는 로거가 수행할 작업을 모른다는 점을 인식하는 것이 중요합니다. 다른 작업을 수행하는 하나 이상의 리스너가 있을 수 있습니다. 예를 들어, 새로운 사용자에게 메시지를 보내 시스템에 오신 것을 환영하는 관찰자가 있을 수 있습니다. 이 접근 방식의 가치는 UserList가 이에 의존하는 모든 개체를 무시하고 주로 사용자 목록을 유지 관리하고 목록이 변경될 때 메시지를 보내는 데 중점을 둔다는 것입니다.

이 패턴은 메모리의 개체에만 국한되지 않습니다. 이는 대규모 애플리케이션에서 사용되는 데이터베이스 기반 메시지 쿼리 시스템의 기반입니다.

명령 모드 체인

명령 체인 패턴은 느슨하게 결합된 주제를 기반으로 하며 핸들러 세트를 통해 메시지, 명령, 요청 또는 기타 모든 항목을 보냅니다. 각 핸들러는 요청을 처리할 수 있는지 자체적으로 판단합니다. 가능한 경우 요청이 처리되고 프로세스가 중지됩니다. 다른 핸들러에 영향을 주지 않고 시스템에서 핸들러를 추가하거나 제거할 수 있습니다. 목록 5에서는 이 패턴의 예를 보여줍니다.

목록 5. Chain.php

<?php
인터페이스I명령
{
함수 onCommand( $name, $args );
}

클래스 CommandChain
{
개인 $_commands = 배열();

공용 함수 addCommand( $cmd )
{
$this->_commands []= $cmd;
}

공용 함수 runCommand( $name, $args )
{
foreach( $this->_commands as $cmd )
{
if ( $cmd->onCommand( $name, $args ) )
반품;
}
}
}

UserCommand 클래스는 ICommand를 구현합니다.
{
공개 함수 onCommand( $name, $args )
{
if ( $name != 'addUser' ) return false;
echo( "'addUser'를 처리하는 UserCommandn" );
사실을 반환;
}
}

MailCommand 클래스는 ICommand를 구현합니다.
{
공개 함수 onCommand( $name, $args )
{
if ( $name != 'mail' ) 반환 false;
echo( "'mail'을 처리하는 MailCommandn" );
사실을 반환;
}
}

$cc = 새로운 CommandChain();
$cc->addCommand( new UserCommand() );
$cc->addCommand( new MailCommand() );
$cc->runCommand( 'addUser', null );
$cc->runCommand( '메일', null );
?>

이 코드는 ICommand 개체 목록을 유지 관리하는 CommandChain 클래스를 정의합니다. 두 클래스 모두 ICommand 인터페이스를 구현할 수 있습니다. 하나는 메일 요청에 응답하고 다른 하나는 사용자 추가에 응답합니다. 그림 5는 UML을 보여줍니다.

그림 5. 명령 체인 및 관련 명령

일부 테스트 코드가 포함된 스크립트를 실행하면 다음과 같은 출력이 표시됩니다.

% PHP 체인.php
'addUser'를 처리하는 UserCommand
'메일'을 처리하는 MailCommand
%

코드는 먼저 CommandChain 개체를 생성하고 여기에 명령 개체의 두 인스턴스를 추가합니다. 그런 다음 두 개의 명령을 실행하여 누가 명령에 응답했는지 확인합니다. 명령 이름이 UserCommand 또는 MailCommand와 일치하면 코드가 실패하고 아무 작업도 발생하지 않습니다. 명령 패턴 체인은 요청 처리를 위한 확장 가능한 아키텍처를 생성할 때 유용하며 이를 사용하여 많은 문제를 해결할 수 있습니다.

전략 패턴

우리가 다루는 마지막 디자인 패턴은 전략 패턴입니다. 이 패턴에서는 알고리즘이 복잡한 클래스에서 추출되므로 쉽게 교체할 수 있습니다. 예를 들어, 검색 엔진에서 페이지 순위를 매기는 방식을 변경하려면 전략 모드를 선택하는 것이 좋습니다. 검색 엔진의 부분, 즉 페이지를 순회하는 부분, 각 페이지의 순위를 매기는 부분, 순위에 따라 결과를 정렬하는 부분에 대해 생각해 보십시오. 복잡한 예에서 이러한 부분은 모두 동일한 클래스에 있습니다. 전략 패턴을 사용하면 정렬 부분을 다른 클래스에 넣어 나머지 검색 엔진 코드에 영향을 주지 않고 페이지 정렬 방식을 변경할 수 있습니다.

더 간단한 예로 Listing 6은 플러그 앤 플레이 정책 세트를 기반으로 사용자 세트를 찾는 방법을 제공하는 사용자 목록 클래스를 보여줍니다.

목록 6. Strategy.php

<?php
인터페이스 전략
{
함수 필터($record);
}

FindAfterStrategy 클래스는 IStrategy를 구현합니다.
{
비공개 $_name;

공개 함수 __construct( $name )
{
$this->_name = $이름;
}

공용 함수 필터($record)
{
return strcmp( $this->_name, $record ) <= 0;
}
}

RandomStrategy 클래스는 IStrategy를 구현합니다.
{
공용 함수 필터($record)
{
rand( 0, 1 ) >= 0.5;를 반환합니다.
}
}

클래스 사용자 목록
{
개인 $_list = 배열();

공개 함수 __construct( $names )
{
if ($names != null )
{
foreach( $name을 $name으로)
{
$this->_list []= $이름;
}
}
}

공개 함수 추가($name)
{
$this->_list []= $이름;
}

공개 함수 찾기($filter)
{
$recs = 배열();
foreach( $user로 $this->_list)
{
if ( $filter->filter( $user ) )
$recs []= $사용자;
}
$recs를 반환합니다.
}
}

$ul = new UserList( array( "앤디", "잭", "로리", "메건" ) );
$f1 = $ul->find( new FindAfterStrategy( "J" ) );
print_r( $f1 );

$f2 = $ul->find( new RandomStrategy() );
print_r( $f2 );
?>

그림 6. 사용자 선택에 사용되는 사용자 목록 및 정책

UserList 클래스는 이름 배열을 둘러싼 래퍼입니다. 여러 전략 중 하나를 사용하여 이러한 이름의 하위 집합을 선택하는 find 메서드를 구현합니다. 이러한 전략은 두 가지 구현이 있는 IStrategy 인터페이스에 의해 정의됩니다. 하나는 사용자를 무작위로 선택하는 것이고 다른 하나는 지정된 이름 뒤의 모든 이름을 선택하는 것입니다. 테스트 코드를 실행하면 다음과 같은 출력이 표시됩니다.

%php 전략.php
정렬
(
[0] => 잭
[1] =>로리
[2] =>메건
)
정렬
(
[0] => 앤디
[1] =>메건
)
%

테스트 코드는 두 전략 모두에 대해 동일한 사용자 목록을 실행하고 결과를 표시합니다. 첫 번째 경우 전략은 J 뒤에 오는 모든 이름을 찾으므로 Jack, Lori 및 Megan을 얻게 됩니다. 두 번째 전략은 이름을 무작위로 선택하여 매번 다른 결과를 생성합니다. 이 경우 결과는 Andy와 Megan입니다.

전략 패턴은 데이터 필터링, 검색 또는 처리 방법에 높은 수준의 유연성이 필요한 복잡한 데이터 관리 시스템 또는 데이터 처리 시스템에 이상적입니다.

결론

이 기사에서는 PHP 애플리케이션에 사용되는 가장 일반적인 디자인 패턴 중 몇 가지를 소개합니다. 더 많은 디자인 패턴이 Design Patterns 책에 나와 있습니다. 건축의 신비로움 때문에 좌절하지 마세요. 패턴은 모든 프로그래밍 언어와 모든 기술 수준에서 작동하는 훌륭한 아이디어입니다.