PHP의 5가지 객체지향 원칙과 인터페이스 격리 원칙에 대한 자세한 설명

이 문서의 예에서는 PHP의 5가지 객체 지향 원칙 중 ISP(인터페이스 격리 원칙)를 설명합니다. 참조를 위해 모든 사람과 공유하세요. 세부 사항은 다음과 같습니다. <br>

애플리케이션을 설계할 때 모듈에 여러 하위 모듈이 포함되어 있는 경우 모듈을 추상화하도록 주의해야 합니다. 모듈이 클래스에 의해 구현된다고 가정하면 시스템을 인터페이스로 추상화할 수 있습니다. 그러나 새로운 모듈 확장 프로그램을 추가할 때 추가할 모듈에 원래 시스템의 일부 하위 모듈만 포함되어 있다면 시스템은 인터페이스에서 모든 메소드를 구현하도록 강제하므로 우리는 일부 멍청한 메소드를 작성해야 합니다. 이러한 인터페이스를 팻(Fat) 인터페이스 또는 오염된 인터페이스라고 합니다. 이러한 인터페이스를 사용하면 시스템에 부적절한 동작이 발생할 수 있으며 이는 잘못된 결과를 초래할 수도 있고 리소스 낭비로 이어질 수도 있습니다.

1. 인터페이스 분리

인터페이스 분리 원칙(ISP)은 클라이언트가 사용하지 않을 일부 인터페이스를 강제로 구현해서는 안 되며, fat 인터페이스의 메소드를 그룹화하고 이를 여러 인터페이스로 대체해야 함을 나타냅니다. 각 인터페이스는 서브모듈. 간단히 말해서, 단일 인터페이스보다 여러 개의 특화된 인터페이스를 사용하는 것이 훨씬 좋습니다.

ISP의 주요 포인트는 다음과 같습니다.

1) 한 클래스가 다른 클래스에 대한 의존성은 가장 작은 인터페이스를 기반으로 해야 합니다.

ISP는 고객(인터페이스 사용 방법)이 사용하지 않는 방법에 의존하도록 강요하지 않는다는 목표를 달성할 수 있습니다. 인터페이스의 구현 클래스는 SRP 원칙에 따라 단일 책임 역할만 제시해야 합니다.

ISP도 가능합니다. 고객 간의 상호 영향을 줄입니다. ---고객이 새로운 책임(변경 필요)을 요구하고 인터페이스를 변경하도록 강요하는 경우 다른 고객 프로그램에 영향을 미칠 가능성은 최소화됩니다.

2) 클라이언트 프로그램은 필요하지 않은 인터페이스 메소드(함수)에 의존해서는 안 됩니다.

클라이언트 프로그램은 필요하지 않은 인터페이스 메소드(함수)에 의존해야 합니다. 필요한 인터페이스에 따라 다릅니다. 클라이언트에 필요한 모든 인터페이스를 제공하고 불필요한 인터페이스를 제거하려면 인터페이스의 순수성을 보장해야 합니다.

예를 들어, 상속할 때 하위 클래스는 상위 클래스에서 사용 가능한 모든 메서드를 상속하며 상위 클래스의 일부 메서드는 하위 클래스에 필요하지 않을 수 있습니다. 예를 들어, 일반 직원과 관리자는 모두 직원 인터페이스에서 상속받습니다. 직원은 매일 작업 로그를 작성해야 하지만 관리자는 그렇지 않습니다. 따라서 작업 로그를 사용하여 관리자를 차단할 수 없습니다. 즉, 관리자는 작업 로그를 제출하는 방법에 의존해서는 안됩니다.

ISP와 SRP는 개념이 일부 겹치는 것을 볼 수 있습니다. 실제로 많은 디자인 패턴은 개념적으로 중복되어 있고, 코드 조각이 어떤 디자인 패턴에 속하는지조차 구분하기 어렵습니다.

ISP는 인터페이스가 클라이언트에게 최소한의 약속을 주며 구체적이어야 한다는 점을 강조합니다. 특정 클라이언트 프로그램의 요구 사항이 변경되고 인터페이스가 강제로 변경되는 경우 다른 클라이언트 프로그램에 영향을 미칠 가능성은 적습니다. 이것은 실제로 인터페이스 오염의 문제입니다.

2. 인터페이스 오염

지나치게 부풀린 인터페이스 디자인은 인터페이스 오염입니다. 소위 인터페이스 오염은 인터페이스에 불필요한 책임을 추가하는 것입니다. 개발자가 단지 인터페이스 구현 클래스 수를 줄이기 위해 인터페이스에 새로운 기능을 추가하면 이러한 설계로 인해 인터페이스가 지속적으로 "오염"되고 "뚱뚱해집니다. " .

"인터페이스 격리"는 실제로 맞춤형 서비스 디자인의 원칙입니다. 인터페이스의 다중 상속을 사용하여 서로 다른 인터페이스를 결합하여 외부 결합 기능을 제공합니다. 즉 "주문형 서비스"를 달성합니다.

인터페이스는 분해해야 하지만 너무 세밀하게 분해할 수는 없으니 응집력이 높다는 기준이 있어야 합니다. 인터페이스에는 몇 가지 기본 기능이 있어야 하며 기본 작업을 고유하게 완료할 수 있습니다.

실제 애플리케이션에서는 다음과 같은 문제에 직면하게 됩니다. 예를 들어, 여러 유형의 데이터베이스에 적응할 수 있는 DAO 구현이 필요한 경우 먼저 데이터베이스 작업의 몇 가지 기본 방법을 규정하는 데이터베이스 작업 인터페이스를 구현해야 합니다. 데이터베이스에 접속, 데이터베이스 추가, 삭제, 수정, 확인, 닫기 등을 할 수 있습니다. 이것은 최소한의 기능을 갖춘 인터페이스입니다. MySQL에 고유하지만 다른 데이터베이스에는 존재하지 않거나 PHP에서 사용할 수 있는 MySQL pconnect 메소드와 같이 성격이 다른 일부 메소드의 경우 이 메소드와 동일한 개념이 다른 데이터베이스에는 존재하지 않으므로 이 메소드는 이 기본 인터페이스에 나타나야 하는데 이 기본 인터페이스에는 어떤 기본 메소드가 있어야 합니까? PDO가 그렇게 말했어요.

PDO는 추상 데이터베이스 인터페이스 계층으로, 기본 데이터베이스 작업 인터페이스가 구현해야 하는 기본 메서드가 무엇인지 알려줍니다. 인터페이스는 높은 수준의 추상화이므로 인터페이스의 메서드는 보편적이고 기본적이어야 하며 변경하기 쉽지 않아야 합니다.

또 다른 질문이 있습니다. 이러한 고유한 메서드를 어떻게 구현해야 합니까? ISP 원칙에 따르면 이러한 메서드는 다른 인터페이스에 존재할 수 있으므로 이 "이기종"이 두 인터페이스를 동시에 구현할 수 있습니다.

인터페이스 오염의 경우 다음 두 가지 처리 방법을 고려할 수 있습니다.

위임을 사용하여 인터페이스를 분리합니다.

다중 상속을 사용하여 인터페이스를 분리하세요.

위임 모드에서는 두 개체가 동일한 요청 처리에 참여합니다. 요청을 수락한 개체는 처리를 위해 다른 개체에 요청을 위임합니다. 위임의 개념은 전략 모드, 프록시 모드 등에 적용됩니다.

예제를 살펴보겠습니다

매우 "두꺼운" 인터페이스를 본 적이 있나요?

예를 들어 보겠습니다. 동물과 관련된 인터페이스가 있으며 코드는 다음과 같습니다.

<br>

1. <?php
   interface Animal{
     public function walk();
     public function speak();
   }

Dog는 이 인터페이스의 특정 구현입니다.

<br>

1. <?php
   require_once "animal.php";
   class Dog implements Animal{
     public function walk(){
       echo "dogs can walk";
     }
     public function speak(){
       echo "dogs can speak";
     }
   }

좋아, 이제 우리는 원합니다 물고기가 헤엄칠 수 있게 만들려면 어떻게 해야 할까요? 인터페이스를 수정해야 하며 이는 개 클래스의 구현에도 영향을 미치며 fish도 다음 코드에 표시된 대로 걷기 및 말하기 메서드를 구현해야 합니다.

동물 인터페이스 클래스:

<br>

1. <?php
   interface Animal{
     public function walk();
     public function speak();
     public function swim();
   }

dog 클래스:

<br>

1. <?php
   require_once "animal.php";
   class Dog implements Animal{
     public function walk(){
       echo "dogs can walk";
     }
     public function speak(){
       echo "dogs can speak";
     }
     public function swim(){
     }
   }

fish 클래스:

<br>

1. <?php
   require_once "animal.php";
   class Fish implements Animal{
     public function walk(){
     }
     public function speak(){
     }
     public function swim(){
       echo "fish can swim";
     }
   }

이때 Animal 인터페이스 클래스는 "뚱뚱한" 인터페이스의 특징을 보여줍니다. 소위 뚱뚱한 인터페이스는 실제로 인터페이스가 모든 구현 클래스에서 필요하지 않은 메소드를 정의한다는 것을 의미합니다. Animal 인터페이스 클래스와 마찬가지로 일부 동물은 수영할 수 없고, 일부 동물은 걷지 못하고, 일부 동물은 날 수 없습니다. 이러한 메서드를 Animal 인터페이스 클래스에 작성하면 나중에 확장하고 유지 관리하는 것이 재앙이 됩니다.

그렇다면 위의 문제를 어떻게 해결할 수 있을까요?

매우 간단합니다. 인터페이스를 개선하고 Animal 인터페이스 클래스를 세 가지 인터페이스 클래스로 나누면 됩니다.

animalCanWalk接口类：

<br>

1. <?php
   interface animalCanSpeak{
     public function speak();
   }

AnimalCanSwim接口类：

<br>

1. <?php
   interface AnimalCanSwim{
     public function swim();
   }

animalCanSpeak接口类：

<br>

1. <?php
   interface animalCanSpeak{
     public function speak();
   }

定义好这几个接口类之后，dog和fish的实现就容易多了，

<br>

1. <?php
   require_once "animalCanSpeak.php";
   require_once "animalCanWalk.php";
   class Dog implements animalCanSpeak,animalCanWalk{
     public function walk(){
       echo "dogs can walk";
     }
     public function speak(){
       echo "dogs can speak";
     }
   }

<br>

接口隔离原则(Interface Segregation Principle, ISP)的概念：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强迫客户依赖于那些它们不用的方法。

위 내용은 PHP의 5가지 객체지향 원칙과 인터페이스 격리 원칙에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!