PHP 인터페이스 격리 원칙(ISP) 사용 사례 분석

이번에는 PHP 인터페이스 격리 원칙(ISP) 사용 사례에 대한 분석을 가져오겠습니다. PHP 인터페이스 격리 원칙(ISP) 사용 시 주의 사항은 무엇입니까? 다음은 실제 사례를 살펴보겠습니다.

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

1. 인터페이스 분리

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

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

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

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

ISP는 또한 고객 간의 상호 상호 작용을 줄입니다. 영향 --- 클라이언트가 인터페이스 변경을 강제하는 새로운 책임(변경 필요)을 요구하는 경우 다른 클라이언트 프로그램에 영향을 미칠 가능성이 가장 적습니다.

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

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

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

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

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

2. 인터페이스의 오염

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

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

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

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

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

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

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

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

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

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

예제를 살펴보겠습니다

매우 "두꺼운" 인터페이스를 접한 적이 있습니까?

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

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

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

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

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

동물 인터페이스 클래스:

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

dog 클래스:

<?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 클래스:

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

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

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

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

animalCanWalk 인터페이스 클래스:

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

AnimalCanSwim 인터페이스 클래스:

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

animalCanSpeak 인터페이스 클래스:

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

인터페이스 클래스 뒤에 정의하세요.

<?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";
  }
}

<?php
require_once "animalCanSwim.php";
class Fish implements AnimalCanSwim{
  public function swim(){
    echo "fish can swim";
  }
}

요약:

인터페이스 분리 원칙(ISP)의 개념: 단일 전체 인터페이스를 사용하는 대신 여러 특수 인터페이스를 사용합니다. 즉, 클라이언트는 필요하지 않은 인터페이스에 의존하지 않습니다.

인터페이스 격리 원칙을 사용할 때 인터페이스의 세분성을 제어하는 ​​데 주의를 기울여야 합니다. 인터페이스가 너무 작으면 시스템에서 인터페이스가 급증하게 됩니다. 인터페이스가 너무 크면 인터페이스에 위배됩니다. 격리 원칙은 유연성이 낮고 사용하기 매우 불편합니다. 일반적으로 인터페이스에는 특정 유형의 사용자에 맞게 사용자 정의된 메서드만 포함하면 되며, 클라이언트는 자신이 사용하지 않는 메서드에 의존하도록 강요되어서는 안 됩니다.

이 기사의 사례를 읽은 후 방법을 마스터했다고 생각합니다. 더 흥미로운 정보를 보려면 PHP 중국어 웹사이트의 다른 관련 기사를 주목하세요!

추천 도서:

PHP 종속성 반전 사례에 대한 자세한 설명

PHP에서 Composer 패키지를 만드는 단계에 대한 자세한 설명

위 내용은 PHP 인터페이스 격리 원칙(ISP) 사용 사례 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!