Sử dụng OOP trong các chủ đề

Tôi thấy rất nhiều plugin sử dụng mã hóa hướng đối tượng khi không thực sự cần thiết.

Nhưng điều tồi tệ hơn nữa là các nhà phát triển chủ đề đang bắt đầu làm điều tương tự. Các chủ đề thương mại và các chủ đề phổ biến miễn phí như Suffusion, thậm chí là chủ đề yêu thích của tôi - Kết hợp, nhét tất cả các chức năng của chúng vào trong một lớp, khởi tạo nó một lần trong hàm.php và chạy các chức năng của nó theo cách thủ tục :)

Wtf? Quan điểm của việc này là gì? Rõ ràng là bạn sẽ không sử dụng hai hoặc nhiều phiên bản của cùng một chủ đề cùng một lúc.

Chúng ta hãy giả sử rằng các plugin làm điều này cho không gian tên (thật vô lý), nhưng lý do chủ đề là gì? Tui bỏ lỡ điều gì vậy?

Lợi thế của việc mã hóa một chủ đề như thế này là gì?

Tôi có thể hiểu sự nhầm lẫn của bạn dựa trên ví dụ bạn cung cấp. Đó thực sự là một cách kém để sử dụng một lớp ... và chỉ vì một lớp được sử dụng, không tạo ra một hệ thống OOP.

Trong trường hợp của Hybrid, họ chỉ sử dụng một lớp để đặt tên cho các hàm của chúng. Xem xét Hybrid là một khung chủ đề , điều này được thực hiện để các chủ đề con có thể sử dụng lại tên hàm mà không cần nhà phát triển phải lo lắng về xung đột tên. Trong nhiều trường hợp, một khung chủ đề (chủ đề gốc) rất phức tạp, nhiều nhà phát triển chủ đề con sẽ không bao giờ hiểu chính xác những gì diễn ra dưới mui xe.

Nếu Hybrid không sử dụng cấu trúc lớp, các nhà phát triển chủ đề con sẽ cần biết tất cả các lệnh gọi hàm hiện có là gì để họ có thể tránh sử dụng lại tên. Và đúng vậy, bạn chỉ có thể tiền tố tất cả các chức năng của mình bằng một con sên duy nhất, nhưng điều đó làm cho mã khó đọc, khó bảo trì và vốn không thể tái sử dụng nếu bạn phát triển các hệ thống khác muốn sử dụng cùng chức năng.

Để trả lời câu hỏi của bạn

Wtf? Quan điểm của việc này là gì? Rõ ràng là bạn sẽ không sử dụng hai hoặc nhiều phiên bản của cùng một chủ đề cùng một lúc.

Không, bạn sẽ không sử dụng hai hoặc nhiều phiên bản của cùng một chủ đề. Nhưng như tôi đã nói, hãy nghĩ về cấu trúc lớp trong trường hợp này như là đặt tên cho các hàm, không tạo ra một thể hiện đối tượng truyền thống. Kết hợp mọi thứ lại với nhau trong một lớp và khởi tạo nó để gọi phương thức ( myClass->method();) hoặc gọi phương thức trực tiếp ( myClass::method();) là một cách rất rõ ràng để sắp xếp không gian tên mọi thứ theo cách có thể đọc lại được.

Tất nhiên, bạn luôn có thể sử dụng một cái gì đó giống như myClass_method();thay vào đó, nhưng nếu bạn muốn sử dụng lại bất kỳ mã nào trong một chủ đề khác, trong một trình cắm thêm hoặc trong khung antoher, bạn phải quay lại và thay đổi tất cả các tiền tố của bạn. Giữ mọi thứ trong một lớp sạch hơn và cho phép bạn phát triển lại và triển khai lại nhanh hơn nhiều.

Chúng ta hãy giả sử rằng các plugin làm điều này cho không gian tên (thật vô lý), nhưng lý do chủ đề là gì? Tui bỏ lỡ điều gì vậy?

Trong phần lớn các tình huống tôi đồng ý với bạn. Tuy nhiên, phần lớn đó đang nhanh chóng suy yếu. Tôi lưu trữ một số trang web trên bản cài đặt MultiSite sử dụng các biến thể của cùng một chủ đề. Thay vì tạo lại cùng một chủ đề lặp đi lặp lại với những khác biệt nhỏ, tôi có một "lớp" duy nhất cho chủ đề chính và tất cả các chủ đề con mở rộng lớp đó. Điều này cho phép tôi xác định chức năng tùy chỉnh cho từng trang web trong khi vẫn duy trì cảm giác đồng nhất chung trên toàn bộ mạng.

Một mặt, các nhà phát triển chủ đề có thể chọn cách tiếp cận dựa trên lớp để không gian tên chức năng của họ (điều này không vô lý nếu bạn làm việc trong môi trường nơi bạn sử dụng lại nhiều đoạn mã giống nhau). Mặt khác, các nhà phát triển chủ đề có thể chọn cách tiếp cận dựa trên lớp để dễ dàng mở rộng theo các chủ đề con.

Lợi thế của việc mã hóa một chủ đề như thế này là gì?

Nếu bạn chỉ sử dụng Hybrid trên trang web của mình, có rất ít lợi thế để biết bạn là người dùng cuối. Nếu bạn đang xây dựng một chủ đề con cho Hybrid, có những lợi thế từ không gian tên và khả năng mở rộng. Nếu bạn làm việc cho ThemeHy điều chỉnh , lợi thế nằm ở việc tái sử dụng mã nhanh chóng, hiệu quả trên các dự án khác của bạn (Prototype, Leviathan, v.v.).

Và nếu bạn là nhà phát triển chủ đề thích một tính năng cụ thể của Hybrid nhưng không phải toàn bộ chủ đề, thì lợi thế nằm ở việc tái sử dụng mã nhanh chóng, hiệu quả trong dự án không kết hợp của bạn (giả sử đó cũng là GPL).

Tốc độ

Chủ đề cơ sở hiện tại của tôi có 13 lớp. Khi tôi xây dựng một chủ đề mới, tôi hoặc sử dụng các lớp này như chúng hoặc tôi mở rộng chúng. Hệ thống đó làm cho quá trình xây dựng một chủ đề mới rất, rất nhanh.

Phạm vi chặt chẽ

Tôi hiếm khi cần các biến toàn cục, bởi vì mọi thứ mà mã của tôi phải biết được ẩn trong các thành viên của lớp. Vì vậy, tôi có thể chia sẻ một biến giữa hai bộ lọc hoặc hành động rất khác nhau mà không có nguy cơ va chạm với các plugin được viết kém.

Bảo trì

Mỗi lớp là một tập tin. Nếu tôi cần cập nhật chủ đề của khách hàng, tôi chỉ cần cập nhật một số tệp. Bất cứ điều gì xảy ra bên trong các lớp là tùy thuộc vào tôi miễn là tôi cung cấp cùng một API.

Một ví dụ: phía trên comment_form();cuộc gọi, tôi sử dụng một hành động đơn giản:

do_action( 'load_comment_class' );
comment_form();

Lớp bình luận nào sẽ được tải quyết định bộ điều khiển của tôi. Chính xác những gì xảy ra bên trong lớp bình luận quyết định lớp cá nhân.

Hãy thử điều này với một cách tiếp cận thủ tục thuần túy và bạn sẽ trở nên điên rồ. :)

Dễ đọc

Sẽ dễ dàng hơn nhiều để đọc lại và hiểu mã của riêng bạn vài tháng sau nếu bạn tách mọi thứ theo nhiệm vụ của nó.

Một số ví dụ cho hệ thống phân cấp lớp hữu ích

• Meta_Box-> được mở rộng bởi Shortdesc_Meta_Boxvà Simple_Checkbox_Meta_Box-> được mở rộng bởiSidebar_Switch
• User_Profile_Addon-> được gia hạn bởi User_Profile_Checkbox(xem Câu hỏi 3255 )
• Comment_Form -> kéo dài bởi {$theme_name}_Comment_Form

Một điểm khác để xem xét: Tốc độ.

if ( !class_exists('cccYourClassName') )  
// VERSUS  
if ( !function_exists('ccc_your_function_name') )

Sau khi xem / in ra, tôi tìm thấy ~ 1.700 chức năng nội bộ và ~ 1.400 chức năng người dùng = ~ 3.100 / 3.200 chức năng VS. ~ 250 Lớp. Tôi đoán điều này nói lên nhiều nhất về việc cần phải tìm kiếm bao nhiêu. Nếu bạn gọi !function_exists('')khoảng 50 - 100 chức năng trong chủ đề của mình ... chỉ cần đặt hẹn giờ cho một chức năng và sau đó bắt đầu thực hiện một số phép toán. Ngay cả khi nó không OOP, đó là một cách tốt để tạo mã

1) có thể tái sử dụng
2) có thể duy trì
3) có thể trao đổi
4) nhanh hơn một chút

Khi bạn xem các lớp khác nhau trôi nổi trên web giúp bạn thực hiện các hộp meta, widget, v.v. nhanh chóng, thì thật tốt khi sử dụng bộ điều khiển như @toscho đã đề cập, bởi vì bạn có thể chỉ cần cắm các lớp ra và vào và chỉ cần thay thế một số dòng trong bộ điều khiển xử lý các lớp của bạn.

Một số ý kiến ​​cho rằng đóng gói là lợi ích duy nhất (hoặc ít nhất là chính) mà OOP mang lại, và sự kế thừa và trạng thái nằm ở đâu đó giữa nhàm chán và xấu xa:

http://obiecte.blogspot.com/2008/09/oop-sucks.html

Tác giả đã nói nhiều hơn về việc sử dụng các lớp / đối tượng như các cấu trúc hơn là các thùng chứa cho các hàm tĩnh, nhưng thật thú vị khi đọc một câu hỏi hoàn toàn khác về câu hỏi, từ một người nằm ngoài trại OOP.

Tôi có thể viết Plugin WordPress tiếp theo của mình trong Haskell.

Oh khá là thảo luận! Tôi phải thừa nhận rằng tôi sử dụng các lớp để đóng gói thường xuyên hơn không. Ý tưởng ở đây là trong các plugin của tôi, tôi có thể gói các hàm của mình trong một lớp và trong lớp đó sử dụng các tên phương thức rất đơn giản, có ý nghĩa chung chung ngay cả trong các plugin khác mà tôi viết. Trong trường hợp đó, các lớp là một thay thế cho các không gian tên, mà tôi buộc phải tránh trong các môi trường 5.2.x.

Mặc dù có một vài trường hợp rằng OOP hữu ích cho tính mô đun, hành động đơn giản bao bọc các chức năng của bạn cũng tạo ra phần thưởng bổ sung cho khả năng mở rộng của plugin chéo. Ví dụ, gần đây tôi đã mở rộng một giải pháp lập hóa đơn dựa trên lớp và để tôi có thể mở rộng lớp chính, thêm mã bổ sung cho các chức năng khác nhau (w / Parent :: cuộc gọi) hoặc thậm chí thay thế các chức năng, mà không cần nội bộ hóa plugin mở rộng.

Mặc dù vậy, lớp bọc cho hầu hết các phần chỉ là một thay thế cho không gian tên.

Điểm phàn nàn về mã bạn không viết là gì?

Nếu bạn không thích mã, hãy tự viết!

Đơn giản. Vấn đề được giải quyết.

Các lập trình viên thích làm công cụ theo cách của họ. Vì vậy, đừng cho rằng bạn có thể nói cho họ biết cách viết mã, uống loại rượu whisky nào, loại thuốc lá nào để hút thuốc hay theo tôn giáo nào. Họ sẽ chỉ gỡ lỗi diatribe như vậy và tiếp tục làm những gì họ muốn. ;-)

Mã không phải là thơ. Code là một biến thể của bài hát "My Way" của Sinatra ...