讓我們來解決本書第 22 條和第 41 條之間明顯的矛盾：
第 22 條：「如果你不想定義型，就不要使用介面。」
此項建議您不應將介面用於不代表真實類型或特定功能的事物。例如，僅使用介面來儲存常數並不是一個好的做法。介面應該用來定義類別應該實現的契約或行為。
第 41 條：「如果你真的想定義一個類型，請使用介面。」
本項討論使用接口，特別是標記接口，來定義一種類型，以可以在編譯時檢查的方式對類進行分類或標記。標記介面不定義方法，但它仍然定義一個邏輯類型，可用於在編譯時檢查類別的行為。
協調項目
理解這兩項的關鍵是定義有用的類型和正確使用介面之間的區別。
第 22 條規定避免對沒有特定功能或行為的事物使用介面。這個想法是應該使用介面來定義類別必須遵循的明確契約。
當您想要定義一個類型來為特定目的對類別進行分類或標記並且可用於編譯時檢查時，第 41 條建議使用介面（包括標記）。
實際應用
第 22 項：避免這種情況：
public interface Constants {
String SOME_CONSTANT = "value";
int ANOTHER_CONSTANT = 42;
}
這並沒有定義型別或行為；它只是一個常數容器，這是對介面的錯誤使用。
第 41 項：使用介面來標記類型：
public interface PhysicalProduct {
// Interface marcadora sem métodos
}
public class Book implements PhysicalProduct {
// Implementação da classe que indica que é um produto físico
}
這裡，PhysicalProduct介面定義了一個邏輯類型，可以檢查並用於特定目的，例如運輸計算，確保只考慮實體產品。
結論
這兩個項目透過提供有關如何以及何時正確使用介面的指導來相輔相成。前提是介面應該用來定義有意義的類型和清晰的契約，無論是透過定義行為的方法還是作為以邏輯和有用的方式對類別進行分類的標記。
以上是對物品和書籍的反思的詳細內容。更多資訊請關注PHP中文網其他相關文章！
