現實生活中實際使用的PHP OOP接口

Question

我是OOP的新手，正在學習使用接口的多態性。 有一個流行的多態示例，該示例根據形狀計算面積。

編碼：

<?php

interface Shape {
          public function calcArea();
}

class Circle implements Shape {
      private $radius;

      public function __construct($radius) {
             $this -> radius = $radius;
      }

      public function calcArea() {
             return $this -> radius * $this -> radius * pi();
      }
}

class Rectangle implements Shape  {
      private $width;
      private $height;

      public function __construct($width, $height) {
            $this -> width = $width;
            $this -> height = $height;
      }

      public function calcArea() {
             return $this -> width * $this -> height;
      }
}
$circ = new Circle(3);
$rect = new Rectangle(3,4);

echo $circ -> calcArea();
echo '<br />';
echo $rect -> calcArea();

?>

這是完全不使用接口的相同代碼：

<?php

class Circle {
      private $radius;

      public function __construct($radius) {
             $this -> radius = $radius;
      }

      public function calcArea() {
             return $this -> radius * $this -> radius * pi();
      }
}

class Rectangle  {
      private $width;
      private $height;

      public function __construct($width, $height) {
            $this -> width = $width;
            $this -> height = $height;
      }

      public function calcArea() {
             return $this -> width * $this -> height;
      }
}
$circ = new Circle(3);
$rect = new Rectangle(3,4);

echo $circ -> calcArea();
echo '<br />';
echo $rect -> calcArea();

?>

兩者都按預期工作，但該接口實際上沒有用！ 到目前為止，OOP似乎只是在增加不必要的復雜性。 與使用switch和if條件一樣，我們使用類和公共接口。 我發現，僅在彼此之間而不是在單獨的類中使用IF或切換條件（只要您不重復重復相同的代碼）實際上更容易。

通常，OOP的唯一好處似乎是在設計API時。 因此，API的最終用戶實際上可以直接訪問所需的方法，而不必調用很多不需要的代碼。

但是，從開發人員的角度來看，您實際上可能還需要對代碼的其他部分進行任何對特定類的修改。 而且，無論如何，開發人員都必須查看代碼的其他部分才能理解其工作方式。 此外，HTML中的內聯PHP將會存在，因此對某種方法的任何修改都可能需要更改聲明的對象的實例。

我想念什么嗎？

Answer 1

我認為這個問題更適合於Programmers SE 。

無論如何：您的最小示例是-最小。 是的，在使用界面的情況下會被認為矯枉過正 ，但也有多數用例，其中執行/指定接口做是有意義的。

如果您正在開發開放源代碼，則即使您當時是唯一的開發人員，也可能希望指定一個接口，以確保將來的貢獻者可以輕松訪問您的代碼並可以提供自己的擴展/項目的補充。

但是，即使在最小的示例中，也存在一些用例：想象一個應用程序，其中應用程序的某些部分通常處理Shape對象。 想象一下，沒關系，要處理哪種實際形狀。

使用該接口，您必須為所有派生類實現該方法。 這允許可伸縮性和可維護性。

另外，請參閱關於同一主題的這篇SO帖子 。

Answer 2

這是一個很好的問題，我看到人們一遍又一遍地問。 因此，我將盡力為您簡化操作（界面部分位於最后） 。

首先，您不必一定在所有地方都使用OOP，大多數wordpress核心代碼是用過程php編寫的（不確定當前版本），這不是一件壞事。 在大多數情況下，它確實可以簡化新程序員的工作，這就是使用OOP的全部要點，即在抽象之上添加抽象，因此，當程序員在開發特定功能時，他不必擔心其他方面。 因此，例如，如果我想存儲注冊表單中的圖像，則將有2個類。 一個用於用戶，另一個用於圖像。 這就是它的樣子。

/*********** User Class ***********/

        Class User
        {
          public function storeUser($request, Image $image)
          {
             // Fetch Image from the form request and pass it to the

             $image = $request->input('image');
             $image->uploadImage($image, $imagePath);

             // Now upload other user attributes
          }
        }

/ ********* Image Class **********/

        Class Image
        {
          public function uploadImage($image, $imagePath){
             // Code to UploadImage
          }
        }

我通常在其中有一個名為users的類和一個名為storeUser的方法，將用戶添加到數據庫中。 現在，我還將擁有另一個名為Image的類，並帶有一個名為uploadImage的方法。

您可能還可以使用功能也做完同樣的事情，但是如果您要使用另一項功能，可以說用戶更新個人資料，刪除舊圖像並上傳新圖像時該怎么辦。 為此，您將必須包含另一個函數，該函數將具有所有的uploadimage代碼和一些其他代碼以刪除先前的圖像。

但是現在您要重復自己，並且避免使用DRY原理（請勿重復自己） 。 但是可以說，您還有另一個deleteUserImage函數，該函數將刪除圖像，然后依次調用上載函數。

因此，如果這是您正在考慮的事情，那么您實際上是在下意識地使用OOP，但是以一種非常混亂的方式，因為類只是函數和變量的集合。 但是您缺少許多其他功能，例如范圍，靜態功能，一些其他很棒的功能以及我最喜歡的$ this :)

添加的抽象數量取決於您的截止日期，將來的可伸縮性等。您不必對抽象絕對痴迷，但是簡單的經驗法則是，抽象越多，代碼就越易於管理和靈活。

讓我們說一個論點，您已經在php和mysql中創建了您的應用程序並啟動了它，但是該應用程序變得比您預期的要受歡迎。 突然間，您有數百萬的用戶，但是您的mysql服務器卻不支持這么大量的用戶，並且您想轉移到另一個數據庫，例如postgres或cassandra，但是您所有的mysql查詢都與php代碼混合在一起，並且沒有實現這一目標的無痛方法，而是從頭開始創建一切。 這是許多大型組織（包括Twitter和Facebook）遇到的普遍問題。 但是，如果您使用抽象創建了應用程序，則所有查詢都放在一個類中，而控制器則放在另一個類中。 您所要做的就是僅修改驅動程序並在幾個文件中查詢，然后您將開始一起使用另一個數據庫。

現在讓我們回到有關接口的原始問題。 您可能會認為接口只是浪費時間，因為它只是要在類中實現的所有方法的列表，對嗎？ 嗯，至少在我開始OOP時對我來說似乎如此。 但是事實證明我很愚蠢，因為那時我還不了解SOLID Principles 。

SOLID實際上是有史以來為編程編寫的5條最佳原理的縮寫 ，它們相互之間很好地支持。 SOLID中的“ O”代表“開放和封閉原則”，這意味着該方法對於更改是封閉的，而對於擴展是開放的。 簡而言之，這意味着一旦有了基本的可運行應用程序，就永遠不要修改界面中已有的方法參數，因為如果其他文件也使用該類，則會破壞它們。 您添加限制的方法是通過接口。 那么如何在不修改方法的情況下添加新功能呢？ 好吧，您不直接修改方法，而是對其進行擴展。