PHP의 중개 모델에 대한 간략한 토론

이전 기사 "PHP의 조합 모드에 대한 심층 분석"에서 PHP의 조합 모드를 소개했습니다. 이 기사에서는 PHP 디자인 패턴의 중재자 모드를 이해하도록 안내합니다.

저번에도 언급했듯이 집 밖에서 일하는 우리는 부동산 중개업자와 깊은 접촉을 하는 경우가 많습니다. 대학 졸업 후 바로 자신이 좋아하는 도시에 집을 살 수 있는 X2세대는 우리의 고려 대상이 아니다. 장기간 집을 임대해야 하기 때문에 업무나 생활의 변화로 인해 1~2년, 3~5년마다 부동산 중개업자와 거래를 해야 할 수밖에 없습니다. 때로는 집을 빌릴 때 집주인의 정보를 반드시 알 필요도 없고, 집주인도 우리의 정보를 알 필요가 없는 경우도 있습니다. 여기서 중개자는 우리의 소통의 다리가 됩니다. 이 상황은 실제로 집주인이 해외로 나가거나 해외에서 할 일이 있어서 집을 완전히 중개인의 손에 맡기는 것과 같습니다. 이러한 상황과 유사하게, 코드 세계에서는 중재자 패턴을 적용한 전형적인 사례입니다.

Gof 클래스 다이어그램 및 설명

GoF 정의: 중간 개체를 사용하여 일련의 개체 상호 작용을 캡슐화합니다. 중재자는 객체가 서로 명시적으로 참조하는 것을 방지하여 느슨하게 결합하고 객체 간의 상호 작용을 독립적으로 변경할 수 있도록 합니다. 여기서는 두 개의 고정 동료 클래스가 있다고 가정하고 서로 통신합니다. , 들어오는 동료가 1일 때 2의 Notify 메소드가 호출됩니다. 이는 2가 1

abstract class Mediator
{
    abstract public function Send(String $message, Colleague $colleague);
}

class ConcreteMediator extends Mediator
{
    public $colleague1;
    public $colleague2;

    public function Send(String $message, Colleague $colleague)
    {
        if ($colleague == $this->colleague1) {
            $this->colleague2->Notify($message);
        } else {
            $this->colleague1->Notify($message);
        }
    }
}

의 메시지를 수신하도록 하는 것과 같습니다. 동료 클래스와 해당 클래스의 특정 구현에 관해서는 여기서 확인해야 할 한 가지가 있습니다. 각 동료 클래스는 중개자만 알고 다른 동료 클래스는 알지 못한다는 것이 중개자의 특징입니다.

abstract class Colleague
{
    protected $mediator;
    public function __construct(Mediator $mediator)
    {
        $this->mediator = $mediator;
    }

}

class ConcreteColleague1 extends Colleague
{
    public function Send(String $message)
    {
        $this->mediator->Send($message, $this);
    }
    public function Notify(String $message)
    {
        echo "同事1得到信息：" . $message, PHP_EOL;
    }
}

class ConcreteColleague2 extends Colleague
{
    public function Send(String $message)
    {
        $this->mediator->Send($message, $this);
    }
    public function Notify(String $message)
    {
        echo "同事2得到信息：" . $message;
    }
}

클라이언트 통화는 비교적 간단해요!

이 모델이 일부 커뮤니케이션 제품을 만드는데 매우 적합하다고 생각하시나요? 예, 소셜 채팅, SNS, 라이브 방송 등은 모두 적합합니다. 이 모델은 사용자를 서로 분리할 수 있고 한 명의 사용자가 모든 관련 사용자 개체를 관리할 필요가 없기 때문입니다

사용자가 다음을 수행할 필요가 없기 때문입니다. 관계를 유지하므로 관계 간의 다대다 유지 관리 문제도 해결됩니다. 동시에 사용자 클래스의 좋은 캡슐화를 유지하면서 관계를 변경하기 위해 사용자 클래스를 수정할 필요가 없습니다. 중개자는 유지 관리를 중앙 집중화하므로 이 클래스가 너무 복잡하고 커질 수 있습니다

따라서 패턴은 만병통치약이 아니므로 비즈니스 시나리오를 이해하고 적절하게 사용해야 합니다중개자는 개체 그룹이 통신하는 상황에 적합합니다. 잘 정의되어 있지만 복잡한 방식으로, 너무 많은 하위 클래스를 생성하지 않고 여러 클래스에 분산된 동작을 사용자 정의하고 싶을 때

기업가로서 저는 프로젝트 관리의 중요성을 알고 있으며, 프로젝트 관리자는 중개인. 조직적인 관점에서 보면 프로젝트 시작과 끝에서 상사로서 누가 코딩을 하는지 신경 쓸 필요 없이 소통하고 싶은 사람은 바로 프로젝트 매니저다. 같은 방식으로 다른 보조 부서에는 재무, 인사, 관리 등이 포함됩니다. 누가 코드를 작성하는지 상관하지 않고 프로젝트 관리자와 소통하여 프로젝트 상태와 조정해야 할 사항을 이해하면 됩니다. 프로젝트 팀에서 코드를 작성하는 사람들은 어떤가요? 누가 그에게 임금을 지불할지, 출석 문제가 어디에 있는지 알 필요가 없습니다. 이 모든 것은 프로젝트 관리자가 해결할 수 있습니다. 따라서 프로젝트 관리자 책임 시스템에 따른 프로젝트 개발은 중개 모델의 전형적인 적용입니다. 우리 휴대폰 공장이 이렇게 빨리 발전하는 이유는 이 프로젝트 매니저들 덕분입니다. 저녁에 성대한 저녁을 대접합시다~~~

전체 코드: https://github.com/zhangyue0503/designpatterns- php/blob/master/15.mediator/source/mediator.php
• Example
• 이번에는 문자 메시지를 보내지 않고 채팅방을 구현해 보겠습니다. 간단한 온라인 채팅방의 요건은 채팅방에 입장한 사용자가 온라인 채팅을 할 수 있도록 하는 것입니다. 중개 모드를 이용하여 이 채팅방을 구현하는 방법을 살펴보겠습니다!
• 채팅방 클래스 다이어그램

전체 소스 코드: https://github.com/zhangyue0503/designpatterns-php/blob/master/15.mediator/source/mediator-webchat.php

$m = new ConcreteMediator();

$c1 = new ConcreteColleague1($m);
$c2 = new ConcreteColleague2($m);

$m->colleague1 = $c1;
$m->colleague2 = $c2;

$c1->Send("吃过饭了吗？");
$c2->Send("没有呢，你打算请客？");

지침

• 중개자가 정보를 주고받는 '채팅방'이라는 사실, 알고 계셨나요?
• 여기서는 사용자 수가 고정되어 있지 않기 때문에 자신을 제외한 사용자가 메시지를 보낼 때 배열로 유지됩니다. , 모두가 이 메시지를 받았습니다
• 사용자는 채팅방에 자유롭게 입장하고 나갈 수 있습니다. 솔직히 말해서 이 예제는 실제로 기능을 거의 구현한 채팅 애플리케이션처럼 보입니다.
• 물론 중개 모델은 의사소통에 정말 적합합니다. .그러나 애플리케이션에 너무 많은 사용자가 진입하면 $users 목록이 점점 더 부풀어오르게 됩니다. 이것이 위에서 언급한 중개 모델의 문제입니다

원본 주소: https://juejin.cn /post /6844903975192363015

저자: 하드코어 프로젝트 매니저

추천 학습: "PHP 비디오 튜토리얼"

위 내용은 PHP의 중개 모델에 대한 간략한 토론의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!