Nhập văn bản rõ ràng trong Groovy: đôi khi hoặc không bao giờ?

Question

[Sau đó: Vẫn không thể tìm ra nếu Groovy có gõ tĩnh (có vẻ như nó không) hoặc nếu bytecode được tạo ra bằng cách gõ rõ ràng là khác nhau (có vẻ như nó là). Dù sao, đối với câu hỏi]

Một trong những khác biệt chính giữa Groovy và các ngôn ngữ động khác - hoặc ít nhất là Ruby - là bạn có thể statically một cách rõ ràng các biến khi bạn muốn.

Điều đó nói rằng, khi nào bạn nên sử dụng gõ tĩnh trong Groovy? Dưới đây là một số câu trả lời có thể tôi có thể nghĩ đến:

1. Chỉ khi có sự cố về hiệu suất. Statically typed variables are faster in Groovy. (hoặc là họ? Một số câu hỏi về liên kết này)
2. Trên giao diện công khai (phương pháp, trường) cho lớp học, vì vậy bạn sẽ tự động hoàn tất. Điều này có thể/đúng/hoàn toàn sai?
3. Không bao giờ, nó chỉ cắt xén mã và đánh bại mục đích sử dụng Groovy.
4. Có khi lớp học của bạn sẽ được thừa hưởng hoặc sử dụng

tôi không chỉ quan tâm đến những gì bạn làm nhưng quan trọng hơn những gì bạn đã nhìn thấy xung quanh các dự án mã trong Groovy. Tiêu chuẩn là gì?

Lưu ý: Nếu câu hỏi này bằng cách nào đó sai hoặc bỏ sót một số danh mục tĩnh động, hãy cho tôi biết và tôi sẽ khắc phục.

Answer 1

Theo kinh nghiệm của tôi, không có chuẩn mực. Một số loại sử dụng rất nhiều, một số không bao giờ sử dụng chúng. Cá nhân, tôi luôn cố gắng sử dụng các kiểu trong các chữ ký phương thức của tôi (cho các tham số và các giá trị trả về). Ví dụ tôi luôn luôn viết một phương pháp như thế này

Boolean doLogin(User user) { 
// implementation omitted 
} 

Mặc dù tôi có thể viết nó như thế này

def doLogin(user) { 
// implementation omitted 
} 

Tôi làm điều này vì những lý do:

1. Documentation: nhà phát triển khác (và bản thân tôi) biết loại nào sẽ được cung cấp và trả về bằng phương pháp mà không cần đọc triển khai
2. Loại An toàn: mặc dù không có thời gian kiểm tra biên dịch trong Groovy, nếu tôi gọi phiên bản được gõ tĩnh doLogin với thông số không phải Người dùng, nó sẽ thất bại ngay lập tức, do đó, vấn đề có thể dễ dàng sửa chữa.Nếu tôi gọi phiên bản được nhập động, nó sẽ thất bại một thời gian sau khi phương thức được gọi và nguyên nhân gây ra lỗi có thể không rõ ràng ngay lập tức.
3. Code Completion: đây là đặc biệt hữu ích khi sử dụng một IDE tốt (tức là IntelliJ) vì nó thậm chí có thể cung cấp hoàn thành cho các phương pháp tự động thêm vào như lớp miền Finders động

Tôi cũng sử dụng các loại khá bit trong việc thực hiện các phương pháp của tôi cho cùng một lý do. Trên thực tế, những lần duy nhất tôi không sử dụng các loại là:

1. Tôi thực sự muốn hỗ trợ nhiều loại. Ví dụ: một phương thức chuyển đổi chuỗi thành một số cũng có thể bí mật một bộ sưu tập hoặc một chuỗi các chuỗi thành số
2. Sự lười biếng! Nếu phạm vi của một biến là rất ngắn, tôi đã biết phương pháp nào tôi muốn gọi, và tôi chưa có lớp được nhập, sau đó tuyên bố loại có vẻ như rắc rối nhiều hơn giá trị của nó.

BTW, tôi sẽ không đặt quá nhiều niềm tin vào bài đăng trên blog mà bạn đã liên kết để xác nhận rằng Groovy đã nhập nhanh hơn nhiều so với Groovy không được nhập. Tôi chưa bao giờ nghe điều đó trước đây, và tôi không tìm thấy bằng chứng thuyết phục.

Answer 2

Groovy không hỗ trợ nhập tĩnh. Xem nó cho chính mình:

public Foo func(Bar bar) { 
    return bar 
} 
println("no static typing") 

Lưu và biên dịch tệp đó và chạy tệp đó.

Answer 3

Tôi đã thấy thông tin loại được sử dụng chủ yếu trong các lớp dịch vụ cho các phương thức công khai. Tùy thuộc vào mức độ phức tạp của danh sách tham số, ngay cả ở đây tôi thường chỉ thấy kiểu trả về được gõ. Ví dụ:

class WorkflowService { 
    .... 
    WorkItem getWorkItem(processNbr) throws WorkflowException { 
     ... 
     ... 
    } 
} 

Tôi nghĩ điều này rất hữu ích vì nó cho người dùng biết rõ loại dịch vụ họ sẽ xử lý và trợ giúp mã hỗ trợ trong IDE.

Answer 4

tôi đã làm việc trên một số dự án Groovy và chúng tôi bị mắc kẹt để ước như:

• Tất cả các loại phương pháp nào phải được xác định.

  public int getAgeOfUser (String userName) { ... }

• Tất cả các biến tin được khai báo sử dụng từ khóa def.

Các quy ước này cho phép bạn đạt được nhiều điều.

Trước hết, nếu bạn sử dụng trình biên dịch chung, mã java của bạn sẽ có thể tương tác với mã groovy của bạn một cách dễ dàng. Thứ hai, những tuyên bố rõ ràng đó làm cho mã trong các dự án lớn dễ đọc hơn và bền vững hơn. Và tự động hoàn thành khóa học cũng là một lợi ích quan trọng.

Mặt khác, phạm vi của phương pháp thường khá nhỏ mà bạn không cần khai báo loại một cách rõ ràng. Bằng cách này, các IDE hiện đại có thể tự động hoàn tất các biến cục bộ của bạn ngay cả khi bạn sử dụng defs.