Có cách nào để xác định lại một gợi ý kiểu cho một lớp con cháu khi mở rộng một lớp trừu tượng không?

Question

tôi sẽ sử dụng các ví dụ sau để minh họa cho câu hỏi của tôi:

class Attribute {} 

class SimpleAttribute extends Attribute {} 



abstract class AbstractFactory { 
    abstract public function update(Attribute $attr, $data); 
} 

class SimpleFactory extends AbstractFactory { 
    public function update(SimpleAttribute $attr, $data); 

} 

Nếu bạn cố gắng chạy này, PHP sẽ ném một lỗi nghiêm trọng, nói rằng Declaration of SimpleFactory::update() must be compatible with that of AbstractFactory::update()

tôi hiểu chính xác những gì này có nghĩa là: Chữ ký phương thức SimpleFactory::update() s phải khớp chính xác với lớp trừu tượng gốc của nó.

Tuy nhiên, câu hỏi của tôi: Có cách nào để cho phép phương pháp cụ thể (trong trường hợp này là SimpleFactory::update()) để xác định lại gợi ý loại cho một hậu duệ hợp lệ của gợi ý ban đầu không?

Một ví dụ sẽ là instanceof điều hành, trong đó sẽ trở thành sự thật trong trường hợp sau đây:

SimpleAttribute instanceof Attribute // => true 

Tôi nhận ra rằng khi một công trình xung quanh, tôi có thể làm cho các loại gợi ý như nhau trong các phương pháp cụ thể, và thực hiện kiểm tra instanceof trong thân phương thức, nhưng có cách nào để thực thi điều này ở mức chữ ký không?

Answer 1

Tôi không mong đợi như vậy, vì nó có thể phá vỡ hợp đồng gợi ý loại. Giả sử một hàm foo lấy một AbstractFactory và được thông qua một SimpleFactory.

function foo(AbstractFactory $maker) { 
    $attr = new Attribute(); 
    $maker->update($attr, 42); 
} 
... 
$packager=new SimpleFactory(); 
foo($packager); 

foo cuộc gọi update và vượt qua một thuộc tính đến nhà máy, mà nó nên đi vì phương pháp chữ ký AbstractFactory::update hứa hẹn có thể mất một thuộc tính. Bam! SimpleFactory có một đối tượng kiểu mà nó không thể xử lý đúng.

class Attribute {} 
class SimpleAttribute extends Attribute { 
    public function spin() {...} 
} 
class SimpleFactory extends AbstractFactory { 
    public function update(SimpleAttribute $attr, $data) { 
     $attr->spin(); // This will fail when called from foo() 
    } 
} 

Trong thuật ngữ hợp đồng, lớp hậu duệ phải tôn trọng hợp đồng của tổ tiên của họ, có nghĩa là các thông số chức năng có thể có được cơ sở hơn/ít hơn quy định/cung cấp một hợp đồng yếu và trở về giá trị có thể được bắt nguồn hơn/nhiều hơn quy định/cung cấp hợp đồng mạnh hơn. Nguyên tắc được mô tả cho Eiffel (được cho là ngôn ngữ thiết kế theo hợp đồng phổ biến nhất) trong "An Eiffel Tutorial: Inheritance and Contracts". Sự suy yếu và tăng cường của các loại là ví dụ của contravariance and covariance, tương ứng.

Trong các thuật ngữ lý thuyết khác, đây là ví dụ về vi phạm LSP. Không, không phải rằngLSP; các Liskov Substitution Principle, trong đó nói rằng các đối tượng của một loại phụ có thể được thay thế cho các đối tượng của một siêu kiểu. SimpleFactory là một loại phụ của AbstractFactory và foo mất một số AbstractFactory. Do đó, theo LSP, foo phải mất SimpleFactory. Làm như vậy gây ra lỗi "Gọi đến không xác định", có nghĩa là LSP đã bị vi phạm.

Answer 2

Câu trả lời được chấp nhận là chính xác trong việc trả lời OP rằng những gì ông đã cố gắng làm vi phạm Nguyên tắc thay thế Liskov. OP nên sử dụng giao diện mới và sử dụng bố cục thay vì thừa kế để giải quyết vấn đề chữ ký chức năng của mình. Sự thay đổi trong vấn đề ví dụ của OP là khá nhỏ.

class Attribute {} 

class SimpleAttribute extends Attribute {} 

abstract class AbstractFactory { 
    abstract public function update(Attribute $attr, $data); 
} 

interface ISimpleFactory { 
    function update(SimpleAttribute $attr, $data); 
} 

class SimpleFactory implements ISimpleFactory { 
    private $factory; 
    public function __construct(AbstractFactory $factory) 
    { 
     $this->factory = $factory; 
    } 
    public function update(SimpleAttribute $attr, $data) 
    { 
     $this->factory->update($attr, $data); 
    } 

} 

Ví dụ mã trên thực hiện hai điều: 1) Tạo giao diện ISimpleFactory rằng tất cả các mã phụ thuộc vào một nhà máy cho SimpleAttributes sẽ mã chống lại 2) Thực hiện SimpleFactory sử dụng một nhà máy chung sẽ đòi hỏi SimpleFactory đưa qua một constructor Ví dụ của lớp dẫn xuất AbstractFactory mà nó sẽ sử dụng trong hàm cập nhật từ phương thức ghi đè giao diện ISimpleFactory trong SimpleFactory.

Điều này cho phép bất kỳ phụ thuộc nào khi nhà máy chung được đóng gói từ bất kỳ mã nào phụ thuộc vào ISimpleFactory, nhưng cho phép SimpleFactory thay thế bất kỳ nhà máy nào có nguồn gốc từ AbstractFactory (Satisfying LSP) mà không phải thay đổi bất kỳ mã nào (mã gọi cung cấp sự phụ thuộc). Một lớp dẫn xuất mới của ISimpleFactory có thể quyết định không sử dụng bất kỳ cá thể dẫn xuất AbstractFactory nào để thực thi chính nó, và tất cả mã gọi sẽ được che chắn từ chi tiết đó.

Thừa kế có thể có giá trị lớn, tuy nhiên, đôi khi Thành phần bị bỏ qua và cách ưu tiên của tôi là giảm khớp nối chặt chẽ.