2009-02-11 25 views
23

Tôi không thể hiểu động lực của các tác giả PHP để thêm gợi ý kiểu. Tôi hạnh phúc sống trước khi nó xuất hiện. Sau đó, khi nó được thêm vào PHP 5, tôi bắt đầu chỉ định các loại ở khắp mọi nơi. Bây giờ tôi nghĩ rằng đó là một ý tưởng tồi, như xa như gõ vịt đảm bảo khớp nối tối thiểu giữa các lớp học, và thúc đẩy việc mô-đun hóa và tái sử dụng mã.(Khi nào) tôi nên sử dụng loại gợi ý trong PHP?

Cảm giác như kiểu gợi ý chia ngôn ngữ thành 2 phương ngữ: một số người viết mã theo kiểu ngôn ngữ tĩnh, với gợi ý, và những người khác gắn vào mô hình ngôn ngữ động cũ tốt. Hay đó không phải là tình huống "tất cả hay không"? Tôi có nên trộn lẫn hai phong cách đó khi thích hợp không?

Trả lời

35

Nó không phải là tĩnh so với gõ động, php vẫn còn năng động. Đó là về hợp đồng cho các giao diện. Nếu bạn biết một hàm yêu cầu một mảng là một trong các tham số của nó, hãy ép nó ngay trong định nghĩa hàm. Tôi thích thất bại nhanh hơn, chứ không phải là lỗi sau này trong hàm.

(Cũng lưu ý rằng bạn không thể chỉ định kiểu gián tiếp cho bool, int, string, float, có ý nghĩa trong bối cảnh năng động.)

+2

Phải, tôi đồng ý. Tôi chỉ cảm thấy rằng tất cả những hợp đồng khắt khe đó bằng cách nào đó xa lạ với ngôn ngữ gõ vịt ban đầu. PHP đã đủ xấu xí và loại gợi ý làm cho nó trông giống như một đống các tính năng không liên quan. –

+4

Tôi không biết, PHP đang phát triển (OOP). Các giao diện nghiêm ngặt cho các kiểu dữ liệu phức tạp có ý nghĩa với tôi. – Mario

+2

Bên cạnh đó, bạn có được những điều tốt nhất của cả hai thế giới, xác định mức độ nghiêm ngặt ở đâu quan trọng, hay không, và để những thứ nhỏ năng động. – Mario

15

Bạn nên sử dụng loại gợi ý bất cứ khi nào mã trong hàm của bạn chắc chắn dựa vào loại thông số được truyền. Mã sẽ tạo ra một lỗi anyway, nhưng gợi ý loại sẽ cung cấp cho bạn một thông báo lỗi tốt hơn.

+1

Vâng, mã của tôi trong PHP chỉ dựa vào sự hiện diện của các phương thức mà tôi gọi đối với một đối tượng tham số được truyền. Tại sao hạn chế bản thân mình với yêu cầu một loại nhất định? –

+5

Trong trường hợp đó, tạo một giao diện cho đối tượng của bạn, nó sẽ thực hiện nó và gõ gợi ý hàm của bạn với tên giao diện đó. Hợp đồng vững chắc. – Mario

+1

True. Luôn luôn (Cũng có thể tiết kiệm một vài trường hợp) typehint để giao diện - không phải lớp bê tông. – troelskn

0

Nếu không có loại gợi ý nó sẽ là không thể đối với các IDE để biết loại một tham số phương thức và do đó cung cấp intellisense thích hợp - trình soạn thảo của bạn có intellisense, phải không? ;). Nó nên được nói rằng tôi chỉ giả sử IDE sử dụng này cho intellisense, vì đây là lần đầu tiên tôi đã nghe nói về loại gợi ý trong PHP (cảm ơn cho btw gợi ý).

+2

Có chú thích phpdoc cho rằng –

+0

Đúng, nhưng các nhận xét không phải là mã, thường là;). – Justin

5

Nếu bạn đã từng quyết định làm loại gợi ý, ít nhất hãy làm điều đó bằng cách sử dụng giao diện thay vì các lớp cụ thể hoặc trừu tượng. Lý do rất đơn giản, PHP không cho phép đa thừa kế nhưng cho phép thực hiện nhiều giao diện. Vì vậy, nếu bất cứ ai cố gắng sử dụng thư viện của bạn, nó sẽ không gặp khó khăn trong việc thực hiện giao diện của bạn như trái ngược với trường hợp anh ta phải mở rộng lớp trừu tượng/bê tông của bạn vì anh ta đã mở rộng một lớp khác rồi.

10

Động lực của nhóm PHP để thêm gợi ý loại là cung cấp cho mọi người sử dụng OOP kiểu Java với một tính năng khác làm nền tảng quen thuộc, thoải mái và hấp dẫn hơn. Điều này, đến lượt nó, sẽ làm cho PHP trở nên "sẵn sàng cho doanh nghiệp" hơn, điều này sẽ giúp Zend với hoạt động kinh doanh cốt lõi của họ.

Tiếp thị sang một bên, ứng dụng có tính năng sử dụng. Nếu bạn đang viết một phương thức hoạt động trên một tham số theo một cách cụ thể sẽ gây ra lỗi không mong muốn (thường là im lặng) nếu tham số là thứ gì đó khác, thì sử dụng loại gợi ý đảm bảo mã sẽ bị hỏng trong quá trình phát triển hơn là phá sản xuất.

-2

Loại gợi ý là điểm tranh luận tại công ty chúng tôi (chủ yếu là người Java thích nó), và tôi là một lập trình viên PHP rất cũ (và lập trình bằng các ngôn ngữ khác).

Lời khuyên của tôi là tránh loại gợi ý và bao gồm xử lý thử/bắt trong mỗi hàm phức tạp.

Loại gợi ý buộc ứng dụng phải dựa vào môi trường xử lý ngoại lệ của người gọi nói chung là xấu và không được kiểm tra, vấn đề chính. Đối với các ứng dụng web, điều này dẫn đến màn hình trắng chết, cho hàng loạt kết quả chỉ đơn giản là một lối thoát chết người mà không cần đăng nhập các tin nhắn tốt trong hầu hết các trường hợp, và bạn đang gãi đầu cố gắng tạo lại vấn đề người dùng hoặc ứng dụng trở lại để giải quyết.

Xử lý ngoại lệ cục bộ cung cấp cho một kịch bản kiểm tra được kiểm soát nhiều hơn bao gồm rác trong các loại dữ liệu và rác trong giá trị dữ liệu, cung cấp bộ kiểm tra hoàn chỉnh hơn so với đường dẫn xử lý ngoại lệ khó kiểm tra trong trình gọi. nhập và mong đợi ngoại lệ.

Kiểm tra ngoại lệ cũng không thành công trong nhiều trường hợp do các vấn đề về phiên bản chồng lên nhau (ví dụ: một số phiên bản PHP như 5.4 không bắt lỗi "dễ bị tổn hại" theo cách thích hợp và đơn giản. vấn đề cụ thể, tuy nhiên trong loại kinh nghiệm của tôi chỉ đơn giản là không cần thiết, làm cho mọi người quen với ngôn ngữ đã gõ chấp nhận PHP tốt hơn mà không nhận ra tác động và gây ra nhiều kịch bản thử nghiệm phức tạp hơn (rất khó để kiểm tra người gọi xử lý kết quả đường dẫn ngoại lệ).

Java và các ngôn ngữ được nhập khác không chấp nhận hoặc hiểu cách tận dụng và hưởng lợi từ các tham số kiểu hỗn hợp mặc định trong PHP ... Họ sẽ học một ngày nào đó nhưng chỉ khi họ nắm lấy cách PHP. ;-)

Bài học hay nhất được học khi phát triển các kịch bản thử nghiệm dựa trên đơn vị PHP mạnh mẽ và thường sẽ làm sáng tỏ lý do loại gợi ý là một nỗi đau ở mông liên quan đến kiểm tra và gây ra nhiều vấn đề hơn là tốt ... Đối với từng ứng dụng của riêng họ và các ứng dụng của tôi chạy tốt hơn và đáng tin cậy hơn và thử nghiệm trở nên hoàn chỉnh hơn với phạm vi bao phủ 100% thường bao gồm các đường dẫn bắt trong các hàm cục bộ.

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