Điểm giao diện trong ngôn ngữ đánh máy yếu như PHP là gì?

Question

Tôi chưa bao giờ có thể hình dung ra điều này. Nếu ngôn ngữ của bạn không kiểm tra kiểu, giao diện nào mang lại lợi ích cho bạn?

Answer 1

Giao diện khiến chương trình của bạn bị lỗi sớm hơn và có thể dự đoán trước hơn khi một lớp con "quên" triển khai một số phương thức trừu tượng trong lớp cha của nó.

Trong OOP truyền thống của PHP, bạn phải dựa vào một cái gì đó như sau để đưa ra một lỗi thời gian chạy:

class Base_interface { 
    function implement_me() { assert(false); } 
} 

class Child extends Base_interface { 
} 

Với một giao diện, bạn sẽ có được thông tin phản hồi ngay lập tức khi một trong các lớp con của giao diện của bạn không thực hiện một phương thức như vậy, tại thời điểm lớp con được khai báo chứ không phải sau này trong quá trình sử dụng nó.

Answer 2

Bạn gặp lỗi nếu bạn chưa thêm các phương thức bắt buộc có cùng chữ ký chính xác.

Answer 3

Giao diện thường được sử dụng với thử nghiệm đơn vị (thiết kế thử nghiệm).

nó cũng cung cấp cho bạn mã ổn định hơn. các giao diện cũng được sử dụng để hỗ trợ các trình vòng lặp (ví dụ: hỗ trợ cho việc tìm kiếm trên các đối tượng) và các bộ so sánh.

Answer 4

Taken từ this link (tiền nó lên độc đáo):

• giao diện cho phép bạn xác định/tạo một cấu trúc chung cho các lớp học của bạn - để thiết lập một tiêu chuẩn cho các đối tượng.
• Giao diện giải quyết vấn đề thừa kế duy nhất - chúng cho phép bạn tiêm ‘chất lượng’ từ nhiều nguồn .
• Giao diện cung cấp cấu trúc cơ sở/gốc linh hoạt mà bạn không nhận được với các lớp học.
• Giao diện tuyệt vời khi bạn có nhiều người lập trình làm việc trên dự án ; bạn có thể thiết lập một cấu trúc lỏng lẻo để các lập trình viên theo dõi và để họ lo lắng về các chi tiết.

Answer 5

Cá nhân tôi tìm thấy một giải pháp gọn gàng khi xây dựng lớp DataAccess có hỗ trợ nhiều DBMS. Mỗi triển khai DBMS phải triển khai thực hiện giao diện DataAccess toàn cục với các hàm như Query, FetchAssoc, FetchRow, NumRows, TransactionStart, TransactionCommit, TransactionRollback, v.v ... Vì vậy, khi bạn mở rộng khả năng thừa nhận dữ liệu của mình, bạn buộc phải sử dụng hàm chức năng được định nghĩa chung. 'ứng dụng lại sẽ không phá vỡ tại một số điểm bởi vì bạn đã tìm ra hàm Query bây giờ sẽ được đặt tên là execQuery.

Giao diện giúp bạn phát triển trong bức tranh lớn hơn :)

Answer 6

Theo ý kiến ​​của tôi, không có điểm, không cần và không có ý nghĩa. Những thứ như giao diện, công cụ sửa đổi hiển thị hoặc gợi ý kiểu được thiết kế để thực thi chương trình "đúng" (theo nghĩa nào đó) mà không thực sự chạy nó. Vì điều này là không thể trong một ngôn ngữ động như php, nên các cấu trúc này là vô dụng. Lý do duy nhất tại sao họ được thêm vào php là làm cho nó trông giống như java, do đó làm cho ngôn ngữ hấp dẫn hơn cho thị trường "doanh nghiệp".

Quên thêm: giảm cân không được đề cập. ; //

Answer 7

Nó có thể được nhập sai, nhưng có loại gợi ý cho các phương pháp: function myFunc(MyInterface $interface) Ngoài ra, giao diện giúp với thử nghiệm và tách mã.

Answer 8

Loại gợi ý trong chữ ký hàm/phương thức cho phép bạn có nhiều quyền kiểm soát hơn về cách giao diện của lớp với môi trường của nó.

Nếu bạn chỉ hy vọng rằng người dùng trong lớp của bạn sẽ chỉ sử dụng đúng đối tượng làm thông số phương pháp, có thể bạn sẽ gặp sự cố. Để ngăn chặn điều này, bạn phải triển khai các kiểm tra và bộ lọc phức tạp sẽ làm cho mã của bạn bị sưng và chắc chắn sẽ làm giảm hiệu suất mã của bạn.

Gợi ý loại cung cấp cho bạn công cụ để đảm bảo khả năng tương thích mà không cần bất kỳ séc viết tay, cồng kềnh nào. Nó cũng cho phép các lớp học của bạn nói với thế giới những gì họ có thể làm và nơi họ sẽ phù hợp.

Đặc biệt trong các khung công tác phức tạp như khung công tác Zend, giao diện giúp bạn sống dễ dàng hơn vì họ cho bạn biết những gì mong đợi từ một lớp học và bởi vì bạn biết những phương pháp để thực hiện để tương thích với một cái gì đó.

Answer 9

loại phục vụ ba chức năng riêng biệt:

• thiết kế
• tài liệu
• thực tế loại kiểm tra

Hai đầu tiên không đòi hỏi bất kỳ hình thức loại kiểm tra ở tất cả. Vì vậy, ngay cả khi PHP đã thực hiện không kiểm tra giao diện, chúng sẽ vẫn là chỉ hữu ích cho hai lý do đó.

Tôi, ví dụ, luôn nghĩ về giao diện của mình khi tôi đang làm Ruby, mặc dù Ruby không có giao diện. Và tôi thường muốn tôi có thể có một số cách để ghi lại các quyết định thiết kế đó trong mã nguồn.

Mặt khác, tôi đã thấy nhiều mã Java sử dụng giao diện, nhưng rõ ràng tác giả chưa bao giờ nghĩ về chúng. Trong thực tế, trong một trường hợp, người ta có thể thấy từ thụt đầu dòng, khoảng trống và một số nhận xét còn sót lại trong giao diện mà tác giả đã thực sự chỉ sao chép và dán định nghĩa lớp và xóa tất cả các thân phương thức.

Bây giờ đến điểm thứ ba: PHP thực tế có giao diện kiểm tra loại. Chỉ vì nó gõ kiểm tra chúng trong thời gian chạy không có nghĩa là nó không gõ kiểm tra chúng tại tất cả. Và, trên thực tế, nó thậm chí không kiểm tra chúng trong thời gian chạy, nó sẽ kiểm tra chúng tại thời gian tải, xảy ra trước khi thời gian chạy là. Và không phải là "kiểm tra kiểu không xảy ra trong thời gian chạy nhưng trước đó" khá nhiều định nghĩa về kiểm tra kiểu tĩnh?