Tôi có nên xác định giao diện trong ngôn ngữ Duck Typed không?

Question

Tôi sắp viết ứng dụng đầu tiên của mình bằng ngôn ngữ gõ vịt (Groovy).

Nếu tôi viết cùng một ứng dụng bằng ngôn ngữ được nhập tĩnh thì tôi cần xác định một số giao diện. Rõ ràng là do việc gõ vịt trong Groovy, chúng không thực sự được yêu cầu. Tại thời điểm này tôi nghĩ rằng nó có thể làm cho tinh thần để xác định chúng anyway như tài liệu hướng dẫn của các phương pháp cần phải được thực hiện trong các đối tượng khác nhau. Tôi có thiếu điểm không?

Answer 1

Tôi đã đọc về điều này gần đây trên SO (và tôi không thể tìm thấy liên kết ngay bây giờ, nhưng đây là một trong những bài viết "tại sao ngôn ngữ động" tốt và câu trả lời lớn S. Lott có nhiều ý kiến) và câu trả lời là:

Bạn có thể. Trong Groovy đặc biệt, bạn có thể định nghĩa các giao diện trong Java hoặc Groovy và triển khai chúng. Tuy nhiên, với cách gõ vịt (Groovy cho phép nhưng cũng cho phép loại rõ ràng) nhiều người sẽ nói "tại sao lại bận tâm?" Nguồn là tài liệu riêng của nó, giao diện nằm trong nguồn, "sử dụng nguồn", v.v.

Cá nhân, điều này làm tôi phát điên - Tôi thích thời gian biên dịch (hoặc thực sự, thời gian dev) mà Java cung cấp tôi, nhưng đó là một cuộc tranh luận khác. Nếu bạn đang sử dụng Groovy, đó là bởi vì bạn muốn viết rằng mã súc tích và rõ ràng tuyệt vời đến từ việc gõ vịt. Trong trường hợp đó, các giao diện cần tránh trừ khi cần thiết.

Chúng cần thiết ở đâu? Giữa các phần của một chương trình và trong API công khai cho một chương trình (mặc dù chúng có thể là các lớp trừu tượng). Nếu không, tôi sẽ nói rằng bạn nên cố gắng tránh chúng bằng các ngôn ngữ được đánh máy. Điều này buộc bạn phải viết các tài liệu trên các lớp, hoặc viết mã rõ ràng đến mức nó giống nhau.

Tôi nghĩ rằng đây là thực tế khủng khiếp, BAO GIỜ đây là một phần của sự chuyển đổi mô hình theo hướng ngôn ngữ động.Và tôi nghĩ rằng nếu bạn tránh tách giao diện khỏi việc triển khai đủ, bạn sẽ hiểu 'lý do' đằng sau nó. Tôi vẫn không, mặc dù nó có rất nhiều để làm với không lặp lại mã (giữ DRY).

Edit: Got một số rõ ràng ra khỏi máy tính :) Một trong những lý do chính không để tách giao diện từ việc thực hiện là để bạn di chuyển ra khỏi một sự phụ thuộc vào loại. Trong kiểu gõ vịt, như bạn đã biết, tôi không quan tâm nếu đó là người triển khai giao diện Vehicle (ví dụ). Tôi chỉ quan tâm nếu nó có phương pháp go với 2 thông số. Vì vậy, bạn càng làm việc với các giao diện, bạn càng viết Java trong Groovy ("bạn có thể viết Fortran bằng bất kỳ ngôn ngữ nào"). Điều này nên tránh, vì các ngôn ngữ mới mở ra cho bạn những thứ mới.

Answer 2

Xác định giao diện là một loại tài liệu trong mã. Với giao diện bạn khai báo rõ ràng những gì bạn mong đợi từ lớp học để đáp ứng nhu cầu của bạn.

PS: groovy không phải là ngôn ngữ của tôi, vì vậy tôi thực sự không biết cho dù đó có thể xác định các giao diện có ở tất cả.

Answer 3

Tôi không quen với tiếng rêu, nhưng nói chung, không, bạn không cần phải xác định giao diện bằng các ngôn ngữ được nhập lỏng lẻo.

1. Bạn sẽ lặp lại chính mình, nếu bạn cần thay đổi chữ ký phương thức, bạn cần thực hiện ở hai nơi chứ không phải một.

2. Mặc dù giao diện có một số sử dụng làm tài liệu, bằng ngôn ngữ được nhập lỏng lẻo, hầu hết các trình lập trình sẽ không mong đợi giao diện và do đó sẽ không tìm kiếm giao diện nếu cần tài liệu.

3. Hầu hết các ngôn ngữ động đều có sẵn IDE tốt cho chúng, với phương thức hoàn thành, làm giảm thêm nhu cầu cho một giao diện riêng biệt.

4. Phương thức có thể bị ràng buộc và không bị ràng buộc bằng ngôn ngữ động. Vì vậy, bạn có thể, và có lẽ sẽ, kết thúc với các đối tượng không tuân theo giao diện. Có một giao diện riêng biệt có thể khiến mọi người khó hiểu khi đọc mã của bạn.

Answer 4

Trong một số trường hợp, có. Tôi có một ví dụ mà tôi đang tạo một lớp Groovy được đưa vào lớp Java bởi Spring. Tôi tạo ra một giao diện sử dụng Generics như thế này:

//interface injected to a java class 
public interface SomeInterface { 
    <T> T getSomething(int version, Long id); 
} 

Sau đó, việc thực hiện groovy trông như thế này:

//Groovy impelentation 
class SomeInterfaceImpl implements SomeInterface { 
    def getSomething(int version, Long id) { 
     //use duck typing to create similar objects based on version 
    } 
} 

dụ của tôi là tôi đang sử dụng JAXB và XJC để tạo ra các đối tượng từ một lược đồ XML và sử dụng chúng trong một dịch vụ web an toàn của Jersey. Tôi đang phiên bản dịch vụ web và các thay đổi là đủ cho phiên bản, nhưng vẫn còn rất nhiều mã có thể được sử dụng lại. Sử dụng các giao diện được chứng minh là có vấn đề, vì vậy tôi đã sử dụng Groovy thay vào đó và di chuyển tất cả các logic tương tự đến lớp Groovy đã đề cập ở trên với kiểu gõ vịt. Các đối tượng chủ yếu là giống nhau với một số thay đổi do đó việc nhập vịt bằng giao diện để chèn vào lớp Java hoạt động hoàn hảo.