이번에는 PHP 종속성 반전 사례에 대해 자세히 설명하겠습니다. PHP 종속성 반전의 주의사항은 무엇인가요? 실제 사례를 살펴보겠습니다.
의존성 역전이란 무엇인가요? 간단히 말하면 종속성 관계를 종속성 인터페이스로 반전시키는 것을 의미합니다. 구체적인 개념은 다음과 같습니다.
1. 상위 모듈은 모두 추상화(상위 모듈)에 종속되어서는 안 됩니다. 클래스는 서브클래스에 의존할 수 없으며 모두 서브클래스에 의존합니다. (추상 클래스의 경우)
2. 추상화는 구체성에 의존할 수 없고 구체성은 추상화에 의존해야 합니다.
여기서 인터페이스는 좁은 의미의 인터페이스가 아니라는 점에 유의하세요.
왜 인터페이스에 의존하나요? 인터페이스는 문제의 추상화를 구현하고 추상화는 일반적으로 상대적으로 안정적이거나 상대적으로 자주 변경되지 않기 때문에 콘크리트는 변경 가능합니다. 따라서 종속성 추상화는 코드 확장 및 런타임 바인딩(다형성)을 구현하기 위한 기초입니다. 추상 클래스의 하위 클래스가 구현되는 한 해당 클래스의 모든 사용자가 사용할 수 있습니다. 여기서는 확장성의 개념이 강조됩니다. 일반적으로 확장성은 알려진 동작의 확장을 의미합니다. 인터페이스에 관해 이야기할 때 인터페이스는 상대적이어야 한다는 점도 언급됩니다. 이는 아무리 디자인 패턴을 사용하더라도 코드를 수정하지 않고는 끊임없이 변화하는 상황을 달성하는 것이 불가능하다는 것을 말해줍니다. 객체지향의 5가지 원칙 중 종속성 역전이 가장 이해하고 구현하기 어려운 원칙이라고 생각합니다.
여기에서는 직원 클래스를 예로 들어 보겠습니다.
<?php interface employee { public function working(); } class teacher implements employee { public function working() { echo 'teaching...'; } } class coder implements employee { public function working() { echo 'coding...'; } } class workA { public function work() { $teacher = new teacher(); $teacher->working(); } } class workB { private $e; public function set(employee $e) { $this->e = $e; } public function work() { $this->e->working(); } } $worka = new workA; $worka->work(); $workb = new workB; $workb->set(new teacher()); $workb->work();
workA에서는 작업 방법이 교사 구현에 의존하고, workB에서는 작업이 추상화에 의존하므로 필요한 개체가 매개변수를 통해 전달될 수 있습니다. 위의 코드는 인터페이스를 통해 어느 정도의 디커플링을 달성하지만 여전히 제한적입니다. 인터페이스를 사용할 뿐만 아니라 팩토리를 사용하면 어느 정도의 분리 및 종속성 반전을 달성할 수 있습니다.
workB에서는 set 메소드를 통해 Teacher 인스턴스가 전달되어 팩토리 패턴이 구현됩니다. 이러한 구현은 여전히 하드 코딩되어 있으므로 코드를 추가로 확장하려면 구성 파일에 이 종속성을 작성하여 workB에 특히 프로그램에 의해 구성된 교사 개체(예: 종속 항목)가 필요함을 나타냅니다. 클래스 파일)이 존재함) 및 로드 구성에 의존하는 구현을 IOC 컨테이너라고 합니다.
IOC(Inversion of Control)의 개념은 많은 기사에서 볼 수 있었습니다. 실제로 IOC는 DIP(Dependence Inversion 원리)와 동의어입니다. IOC를 언급할 때 누군가 DI와 같은 개념을 언급하는 것을 볼 수도 있습니다. DI, 즉 종속성 주입, 일반적으로 DI(종속성 주입)와 DS(종속성 조회)가 IOC의 두 가지 구현이라고 믿어집니다. 그러나 일부 일반적인 개념이 발전하면서 이러한 개념 간의 관계가 모호해졌습니다. 일부 사람들은 IOC가 DI라고 생각합니다. 어떤 사람들은 IOC보다 의존성 주입에 대한 설명이 더 적절하다고 생각하며, 여기서는 이러한 개념 간의 관계가 얽히지 않을 것입니다.
클래식 J2EE 설계에서 DAO 레이어와 Servicen 레이어는 일반적으로 인터페이스 레이어와 구현 레이어로 세분화되며, 종속성은 구성 파일에서 구성됩니다. 이것이 가장 일반적인 DIP 애플리케이션입니다. Spring 프레임워크는 코드에서 IOC 창으로 제어를 제거하는 좋은 IOC 컨테이너입니다. 이는 XML 구성 파일을 통해 수행됩니다. Spring은 실행 중 구성 파일의 설정에 따라 객체 간의 종속성을 설정합니다.
아래 코드에서 볼 수 있듯이
<bean scopre="prototype" class="cn.notebook.action.NotebookListOtherAction" id="notebookListOtherAction"> <property ref="userReplyService" name="userReplyService" /> <property ref="userService" name="userService" /> <property ref="permissionService" name="permissionService" /> <property ref="friendService" name="friendService" /> </bean>
그러나 이러한 설정에는 여전히 문제가 있으며 구성 파일은 점점 더 커지고 이들 간의 관계는 점점 더 복잡해집니다. 또한 애플리케이션과 비즈니스가 변경됨에 따라 코드를 끊임없이 수정하는 악몽에서 벗어날 수 없습니다(여기서 구성 파일은 코드의 일부로 간주됩니다. 그리고 실제 개발에서는 단순히 구성 파일을 수정하는 경우는 거의 없습니다. 일반적으로 구성 파일이 수정되면 해당 코드도 수정됩니다)
PHP에는 Spring을 모방한 구현도 있습니다. 즉, 종속성은 구성 파일에 작성되고 필요한 객체는 구성 파일을 통해 생성됩니다. 그런 코드는 아직도 구현을 위해 구현되어 있는 것 같아요. Srping에서 구성 파일은 클래스의 런타임 종속성뿐만 아니라 트랜잭션 관리, AOP, 지연 로딩 등을 구성합니다. PHP에서 위의 기능을 달성하려면 소비량이 엄청납니다. 언어 관점에서 볼 때, PHP와 같은 동적 스크립팅 언어는 일부 다형성 기능을 구현한다는 점에서 컴파일된 언어와 다릅니다. 둘째, PHP는 Agile 개발 언어로서 빠른 개발, 명확한 로직, 단순하고 이해하기 쉬운 코드를 강조하며, 다양한 디자인 패턴 프레임워크를 추가할 경우 기술 구현 및 운영 효율성 측면에서 바람직하지 않습니다. 종속성 역전의 핵심 원칙은 디커플링입니다. 이 가장 원시적인 원리에서 벗어나는 것은 수레를 말 앞에 놓는 것입니다.
사실 종속성 반전의 원칙은 이미 많은 디자인 패턴에 암시되어 있습니다. 또한 우리는 의도적으로 또는 의도하지 않게 일부 종속성 반전 작업을 수행하고 있습니다. 단지 PHP와 마찬가지로 현재 상대적으로 완전한 IOC 컨테이너가 없으며 아마도 PHP에는 전혀 필요하지 않을 수도 있습니다.
DIP가 충족되는 경우:
1. 각 상위 클래스는 필요한 서비스에 대한 인터페이스 선언을 제안하고 하위 클래스는 이 인터페이스를 구현합니다.
2. 각 상위 클래스는 이 추상 인터페이스를 통해 서비스를 사용합니다.
이 기사의 사례를 읽은 후 방법을 마스터했다고 생각합니다. 더 흥미로운 정보를 보려면 PHP 중국어 웹사이트의 다른 관련 기사를 주목하세요!
추천 도서:
Bootstrap+PHP 다중 이미지 업로드 구현 단계에 대한 자세한 설명
장바구니 기능 구현을 위한 CI 프레임워크 자세한 설명
위 내용은 PHP 종속성 반전 사례에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!