레지스트리 디자인 패턴에 아무런 문제가 있습니까?

Question

레지스트리 디자인 패턴이 PHP를위한 좋은 해결책입니까?

소셜 네트워크 사이트 (페이스 북, 마이 스페이스).

하나의 DB 연결을 만들고 DB 캐시와 세션 클래스를 처리 할 수있는 데이터베이스 클래스가 있다고 가정 해 봅시다. 캐시 클래스는 항목을 캐시하고 검색 할 수있게 해줍니다. 그래서 내 사이트의 모든 페이지에서 액세스 할 수 있어야하는 3 가지 기본 클래스입니다. 지난 1 시간 동안 레지스트리 패턴을 검토 한 결과, 아마도 완벽한 솔루션이라고 생각합니다. 내 데이터베이스, 세션 및 캐시 개체를 레지스트리 개체에 저장 한 다음 레지스트리 개체를 모든 페이지 또는 다른 모든 클래스에 삽입하고 데이터베이스, 세션 및 캐시에 액세스 할 수 있습니다.

싱글 톤 패턴을 사용하기 전에 모든 페이지 또는 다른 클래스의 내 모든 MAIN 클래스 3 개에 대해 내 싱글 톤 메서드를 호출해야했습니다.

그래서 저는 레지스트리 클래스를 사용하는 것에 대한 단점이 있습니까? 내가 볼 수있는 1은 어떤 수업이 어떤 다른 수업 등에 의존하는지 보는 것이 어려울 수도있는 것 같습니다. 다른 사람이 다음에 대한 좋은 해결책처럼 보이는 또 다른 게시물을 보았습니다. 여기에 사용자 레지스트리 클래스에 대한 또 다른 게시물이 있습니다. 여기에는 레지스트리에 설정이 저장되어 있으며 레지스트리 객체가 전달되는 다른 모든 클래스에서 액세스 할 수 있습니다. 나는 그 기능을 잘 활용할 것이라고 확신한다.

그래서 여기서 유일한 질문은 내가 누락되었거나 내가 열렬한 로또를 했나요?

---

UPDATE

또한 ... 나는 이런 식으로 뭔가를해야,

$this->session = $registry->getObject('session'); 

또는이 대신

$this->registry->session = $registry->getObject('session'); 

을에서 개체를 저장하는 레지스트리를 사용하는 경우 두 번째 방법은 아마도 쉽게 이해할 수있는 것처럼 보입니다. 그리고 그 물체는 어디서 왔는가?

Answer 1

Singleton의 레지스트리를 의미합니까? 그렇다면 3 개의 전역 객체에 대한 액세스가 실제로 필요하지만 다른 객체 내부에 포함되어있는 것처럼 들립니다. 당신은 클래스 Cache, Sessions 및 Database을 정의 cache.php, sessions.php 및 database.php를 쓴 경우

그래서, 당신은 registry.php에 정의 된 Registry 객체 내부에 그들 모두를 포함합니다.

우선 인스턴스 생성의 순서를 이런 방식으로 제어하는 ​​것이 좋습니다. cache.php, sessions.php 및 database.php의 require_once를 수행하는 것보다 낫습니다. 클래스 내부뿐만 아니라 클래스의 단일 전역 인스턴스도 정의 할 수 있습니다. 이는 인스턴스화의 순서를 사용자가 포함/요구하는 방법에 따라 제어합니다. 종류의 천박. 레지스트리 객체를 생성하는 것이 더 좋으며, 객체가 만들어지고 $registry 글로벌이되면 가장 먼저하는 일은 순서와 원하는 방식으로 전역 객체를 제어하는 ​​것입니다.

두 번째로 단일 $ Registry 글로벌을 가진 단일 Registry.php를 갖는 것이 좋습니다. 다양한 파일에서 전역을 정의하면 관리하기가 어려워집니다.

나는 당신과 동의 했으므로 나는 중요한 질문을 던집니다.

$registry->getObject('session'); 
$registry->getObject('database'); 
$registry->getObject('cache'); 

대 :

$registry->getSession(); 
$registry->getDatabase(); 
$registry->getCache(); 

가 개인적으로, 나는 후자를 좋아하는 당신이 다른 것을보고 어떻게. 당신은 수퍼 - 일반 getObject 통해 얻은 세션 개체를 참조하는 문자열 "세션"을 사용하지 않습니다. 대신, 당신은 getSession()을 사용하여 세션을 얻습니다. 그것은 더 잘 읽는다.

레지스트리는 결국 세 가지 전역 변수를 모두 알고 있으므로 명시 적으로 만듭니다. 따라서 이미 단일 목적으로 고정되어 있습니다. 단일 목적에 묶인 구체적인 방법을 추가하는 것은 "약"또는 "나쁨"이 아닙니다. 대신, 나는 코드가 적고 눈알이 더 쉽다고 생각합니다.