Chiến lược viết lại các lớp học


7

[TL: DR]
Tôi có Core_Class_ACore_Class_B extends Core_Class_A.
Tôi cần phải viết lại cả hai và thêm một chức năng chung.

Vì vậy, tôi đã thực hiện điều này : Custom_Class_A extends Core_Class_A.
Câu hỏi là tôi nên sử dụng cái nào từ bên dưới (ngón tay cái lên và ngón cái xuống cho mỗi cái):

  1. Custom_Class_B extends Custom_Class_A
  2. Custom_Class_B extends Core_Class_B

[Phiên bản đầy đủ] Tôi đang làm việc trên một tiện ích mở rộng có thêm bộ lọc mới trong điều hướng được xếp lớp: trong kho / hết hàng (bạn sẽ thấy nó công khai sau vài ngày).
Mã, không có vấn đề lớn cho đến nay, chiến lược ... Tôi có nghi ngờ của tôi.
Vì không có sự kiện nào tôi có thể sử dụng trong phần điều hướng được xếp lớp để thêm bộ lọc mới của mình, tôi đã phải viết lại 2 khối: Mage_Catalog_Block_Layer_ViewMage_CatalogSearch_Block_Layer. (Nếu ai đó có ý tưởng tốt hơn, vui lòng chia sẻ, nhưng điều này không nằm trong phạm vi câu hỏi).

Đối với Mage_Catalog_Block_Layer_Viewtôi, tôi đã làm như Vinai nghĩ về tôi một cách gián tiếp ( xem đánh giá này về một trong những tiện ích mở rộng của Vinai ).
Tôi đã thêm các phương thức tôi muốn viết lại, chỉ cần gọi parent::methodName()và gửi một sự kiện mà mọi người có thể quan sát.

Dưới đây là một ví dụ cho phương pháp _initBlocks. Phương pháp mới của tôi trông như thế này:

protected function _initBlocks()
{
    parent::_initBlocks(); //call the parent method
    //dispatch an event that I can observe and add my logic.
    Mage::dispatchEvent('catalog_layer_view_init_blocks', array('block' => $this));
}

Nhưng vấn đề xảy ra Mage_CatalogSearch_Block_Layer. Khối này mở rộng cái đầu tiên Mage_Catalog_Block_Layer_View.

Ví dụ tôi cần viết lại phương thức _initBlocksnhư hình trên. Nhưng vấn đề là Mage_CatalogSearch_Block_Layerkhông có _initBlocksphương pháp riêng . nó sử dụng một từ lớp cha Mage_Catalog_Block_Layer_View.
Tôi phải làm gì ở đây?
Tôi có nên sử dụng cùng một hệ thống như trên hay tôi chỉ nên làm cho lớp mới [Namespace]_[Module]_Block_Catalogsearch_Layercủa mình mở rộng lớp của riêng tôi mà tôi đã tạo để viết lại Mage_Catalog_Block_Layer_Viewvà chỉ sao chép các phương thức khác nhau từ Mage_CatalogSearch_Block_Layer?.


Đây không phải là ý kiến ​​dựa trên nếu bạn nêu những ưu điểm và nhược điểm cho từng phương pháp.
Marius

Đặc điểm sẽ là cách tiếp cận tốt nhất IMHO
philwinkle

@philwinkle. Tôi đồng ý, nhưng có một lỗ hổng trong kế hoạch xấu xa của bạn. Giống như tôi đã giải thích với Flyingmana cho câu trả lời dưới đây, điều này cũng cần phải hoạt động cho PHP 5.3.
Marius

Câu trả lời:


12

Sau khi xem xét vấn đề của bạn với sơ đồ kế thừa lớp rất cơ bản này (nhân tiện xin lỗi vì bản vẽ xấu), tôi nói rằng tốt hơn là tiếp tục với cách tiếp cận bạn đã thực hiện và tạo Custom_Class_B extends Core_Class_B.

di sản

Đối với bản vẽ này, có vẻ rõ ràng với tôi rằng bạn sẽ bỏ lỡ chức năng mở rộng từ Core_Class_Bphiên bản 1 (V1) và bạn sẽ cần sao chép chức năng này từ Core, đây không phải là một cách tiếp cận tốt.

V2 là minh bạch hơn trong trường hợp này.


3
+1 cho câu trả lời tuyệt vời và bản vẽ chỉ giúp bán nó :)
philwinkle

5

Đầu tiên, bạn không bao giờ nên chọn một cách tiếp cận mà bạn cần sao chép các phương thức của một lớp khác, nếu bạn có các lựa chọn khác. Ngay khi chúng thay đổi, bạn sẽ nhận được các vấn đề cập nhật và nhật ký công việc.

Mở rộng chúng và thực hiện phương pháp của riêng bạn một lần nữa là sự lựa chọn tốt hơn. Rõ ràng bạn không nên sao chép ở đây một lần nữa. Sử dụng một người quan sát là một cách tốt để tránh sao chép mã ở đây, một cách khác là sử dụng Tính năng TRAIT PHP, cho phép chia sẻ mã giữa các lớp.


Thật không may, tôi không thể sử dụng các đặc điểm vì điều này cũng hoạt động trên php 5.3. Ngoài ra một số mã phải được nhân đôi trong trường hợp của tôi. Hoặc tôi sao chép mã từ lớp lõi hoặc từ mã tôi đã tạo ở bước 1, khi viết lại lớp đầu tiên. Nhưng tôi hiểu ý của bạn. Tôi nghĩ rằng tôi không nên sao chép mã từ lõi. Tốt hơn mã của riêng tôi, bởi vì tôi có quyền kiểm soát nó. Cảm ơn.
Marius
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.