2009-11-19 24 views
5

Cách tốt nhất để giải quyết các chức năng "tiện ích" trong khuôn khổ OOP PHP là gì? Ngay bây giờ, chúng tôi chỉ có một tập tin với một số chức năng cần thiết trong suốt hệ thống. (Ví dụ, một hàm distribute() chấp nhận một giá trị và một mảng, và trả về một mảng với giá trị được phân phối theo cùng tỷ lệ và cùng một khóa với mảng đầu vào.)Tiện ích tập tin trong php?

Tôi luôn cảm thấy "bẩn" khi sử dụng vì nó hoàn toàn không hướng đối tượng. Có thực hành tốt hơn để di chuyển chúng vào các lớp khác nhau như các phương pháp tĩnh hay chỉ là một cách giải nghĩa ngữ nghĩa? Hay chỉ có một cấp độ trong một khuôn khổ mà một số thứ sẽ rơi ra ngoài cấu trúc OOP?

Trả lời

3

Tôi luôn thực dụng hơn về các câu hỏi như thế này.

Nếu bạn muốn đi toàn OOP, bạn nên gắn chúng vào các lớp học. Tuy nhiên, các lớp này chỉ là các lớp chứa, vì chúng không thực sự đại diện cho các đối tượng thuộc loại nào.

Ngoài ra: việc sử dụng các lớp học sẽ yêu cầu bạn phải có một thể hiện của lớp đó, sử dụng mẫu đơn hoặc khai báo mọi hàm tĩnh. Điều đầu tiên là chậm hơn (được, có thể không nhiều, nhưng trong một khung công tác lớn như vậy cũng lớn, đặc biệt là trong các ngôn ngữ thông dịch như PHP), trong khi thứ hai và thứ ba chỉ đơn giản là vô dụng và đơn giản là trình bao bọc OOP cho một tập hợp các chức năng (đặc biệt là phương pháp thứ ba).

EDIT: Hãy chứng minh cho tôi sai. Tôi có thể. Tôi không quá kinh nghiệm và luôn thấy nó theo cách đó, nhưng tôi có thể sai.

+0

+1 câu trả lời hay. –

+1

Đã chọn. Không có vấn đề gì để biến mọi thứ thành các đối tượng chỉ vì lợi ích của 100% OOP. –

+1

Lợi ích của việc đẩy các hàm vào một trình bao bọc OOP và khai báo chúng là tĩnh, khi bạn gọi các hàm, nó rõ ràng rõ ràng cho các độc giả của mã nơi các hàm được định nghĩa. Tôi sử dụng kỹ thuật này để thực hiện mô phỏng các không gian tên. – jkndrkn

2

Tôi luôn nghĩ về các chức năng tiện ích như phần mở rộng của các hàm php chuẩn. Họ không phải là đối tượng theo định hướng bởi vì bạn không thực sự nhận được bất kỳ lợi ích từ làm cho họ OO.

5

Tôi có xu hướng tạo lớp Util() chỉ chứa các phương pháp tĩnh, không có thuộc tính và không được kế thừa từ đó. Về cơ bản, nó hoạt động như một "không gian tên" cho một loạt các chức năng tiện ích. Tôi sẽ cho phép lớp này phát triển về kích thước, nhưng đôi khi sẽ chia các phương thức thành các lớp riêng của chúng nếu rõ ràng rằng các phương thức đó được thiết kế chỉ để làm việc với một số loại dữ liệu nhất định hoặc nếu rõ ràng là một nhóm các phương thức liên quan được nhóm lại thành một lớp cùng với, có lẽ, một số thuộc tính.

Tôi nghĩ rằng hoàn toàn OK để đi chệch khỏi các thực hành OOP hoàn toàn miễn là mã bị lệch được tổ chức tốt và không tạo ra lỗ hổng kiến ​​trúc trong hệ thống của bạn khiến khó hiểu và duy trì.

+0

Tôi không đồng ý với phần đầu tiên - đặc biệt là với lớp Util. Chỉ cần đọc câu trả lời của tôi để xem tại sao. Tuy nhiên, những gì bạn viết sau đó khiến tôi suy nghĩ. Nếu những tập hợp con đó không chỉ là một tập hợp các hàm tĩnh và không có gì khác, nhưng ví dụ có một số thuộc tính kết hợp (ví dụ xấu, nhưng chỉ có một số thuộc tính: xem trợ giúp trong một lớp với chế độ xem là thành viên lớp - Tôi hy vọng bạn nhận được điểm). +1 – Franz

+0

Darn, tôi đã quên giới hạn bỏ phiếu của mình. Lấy làm tiếc. Bốn giờ nữa;) – Franz

+0

Tôi thực sự có thể thấy việc sử dụng một lớp Util chung để giữ tất cả các chức năng nhỏ gọn, giữ chúng sạch, gần nhau và dưới một "không gian tên" chung là đối tượng. Thật vậy, bạn cần phải xác định chúng tĩnh nhưng hey, có gì sai với điều đó? – ChrisR

Các vấn đề liên quan