Bạn có thể có quá nhiều "động" trong các ngôn ngữ động không?

Question

Trong vài tháng qua tôi đã thực hiện chuyển đổi từ Java sang Groovy và tôi có thể đánh giá cao nhiều lợi ích mà nó mang lại: ít mã, đóng, xây dựng, MOP. kiểm tra, vv

Tuy nhiên, tôi đã bị "đồng ý" bởi đồng nghiệp của tôi rằng mã của tôi không đủ hấp dẫn. Cụ thể, tôi vẫn khai báo kiểu cho các tham số và trường, có xu hướng sử dụng thừa kế và đa hình thay vì gõ vịt vv. Có vẻ như với tôi trong những tình huống này không chỉ là động và tĩnh, mà còn năng động so với mô hình hướng đối tượng loại tiến thoái lưỡng nan. Trong những trường hợp đó tôi vẫn có khuynh hướng thích OO hơn. Tôi cảm thấy rằng mô hình OO có giá trị lớn trong tiền đề cơ bản của nó trong việc cho phép bạn trừu tượng hóa và liên kết các cấu trúc mã của bạn với các khái niệm thực tế cụ thể.

Vì vậy, đây là những câu hỏi cụ thể tôi cần được giúp đỡ với:

1. Tôi có nên khai báo các loại cho các thông số của tôi, lĩnh vực, vv?

2. Tôi có nên khai báo khối mã là đóng khi phương pháp đơn giản sẽ thực hiện?

3. Khi nào tôi nên sử dụng cách nhập vịt thay vì công văn đa hình. Ví dụ, trong groovy tôi có thể làm động vật. "$ Action"() hoặc def animal; animal.action(), thay vì Animal animal = new Dog(); animal.action(). Tôi có thể nhìn thấy vấn đề đầu tiên trong bối cảnh nguyên tắc Open-Closed, nhưng bất kỳ lý do nào khác để thích sự đa hình phong cách OO?

4. Khi nào tôi nên sử dụng giao diện bằng tiếng groovy (nếu có)?

Tôi chắc chắn rằng có một số tình huống khó xử tương tự khác mà tôi không viết được. Tôi cũng nghĩ rằng những câu hỏi này có giá trị không chỉ cho groovy, mà còn cho bất kỳ ngôn ngữ động nào khác. Ý kiến ​​của bạn là gì?

Answer 1

.1. Tôi có nên khai báo các kiểu cho các tham số, trường, v.v. không?

Tôi có xu hướng tuyên bố loại trên các lớp được sử dụng như một phần của API công khai, những thứ mà các nhà phát triển khác sẽ tiêu thụ rất nhiều hoặc tôi muốn một số trợ giúp tự động bổ sung từ IntelliJ. Nếu không tôi 'def' mọi thứ.

.2. Tôi có nên khai báo khối mã như đóng cửa khi phương pháp đơn giản sẽ làm gì?

Tôi sử dụng các phương pháp trừ khi đó là phương pháp tôi dự định truyền xung quanh dưới dạng biến. Mặc dù có toán tử dereference "foo. & bar" phương pháp, hầu hết các dev không biết về điều này và bị nhầm lẫn bởi nó khi chúng chạy trên nó. Tôi cũng sử dụng các bao đóng khi nó là một đoạn mã nhỏ rõ ràng vẫn còn trong một phương pháp lớn hơn là đặt vào phương pháp riêng của nó cho các mục đích mô tả.

.3. Khi nào tôi nên sử dụng cách gõ vịt thay vì công văn đa hình. Ví dụ, trong groovy tôi có thể làm động vật. "$ Action"() hoặc def animal; animal.action(), thay vì Animal animal = new Dog(); animal.action(). Tôi có thể nhìn thấy vấn đề đầu tiên trong bối cảnh nguyên tắc Open-Closed, nhưng bất kỳ lý do nào khác để thích sự đa hình phong cách OO?

Tôi chỉ sử dụng động vật. "$ Action"() khi tôi cần mức độ gián tiếp đó vì tên phương pháp khác nhau dựa trên đường dẫn thực thi mã (thường xuyên nhất trong quá trình lập trình meta nặng). Tôi sử dụng Animal animal = new Dog(); animal.action() khi tôi muốn trợ giúp của IDE với tính năng tự động hoàn thành, hoặc cấp độ tài liệu đó là hữu ích cho sự rõ ràng của mã (và không bị tổn thương do sự bực bội thêm có thể rõ ràng hoặc bị ràng buộc).

.4. Khi nào tôi nên sử dụng giao diện trong groovy (nếu bao giờ)?

Tôi rất hiếm khi sử dụng chúng. Tôi có thể thấy việc sử dụng chúng chủ yếu là tài liệu về các trường dự kiến ​​cho một cuộc gọi API công khai hoặc có thể là giao diện điểm đánh dấu để giúp phân biệt một nhóm các lớp với một lớp khác từ góc độ lập trình meta. Chúng ít hữu ích hơn nhiều so với trong java.

Answer 2

Tôi nghĩ với Groovy, bạn nên ưu tiên cách đơn giản nhất để làm điều gì đó và chỉ quay lại các tính năng của rãnh khi chỉ có tình huống gọi nó. (Giống như khi viết macro hoặc tạo multimethods trong Clojure, nếu bạn thấy mình tiếp cận những công cụ đó rất nhiều bạn nên tự hỏi mình.) Cách tiếp cận thận trọng của bạn có vẻ ổn với tôi, có thể đồng nghiệp của bạn hơi say với sức mạnh mới tìm thấy của họ . (Đây không phải là lần đầu tiên.)

Điều tốt về việc có một ngôn ngữ linh hoạt như Groovy là bạn có thể bắt đầu với cách tiếp cận thận trọng như bạn thích bạn biết mình có nhiều lựa chọn thay thế mạnh hơn khi bạn cần chúng. Bạn biết đấy, "điều đơn giản nhất có thể hoạt động."

Cụ thể hơn là thích nhập vịt trên giao diện và không làm phiền với các kiểu tham số có vẻ như nó có thể là một điều tốt, nó có thể làm cho việc cung cấp mocks trở nên dễ dàng hơn nhiều.

Answer 3

Tùy theo những gì mọi người cảm thấy thoải mái. Tôi thích sử dụng declerations loại và các cuộc gọi phương thức vì tôi cảm thấy thoải mái trong Java. Mã tôi viết phải được duy trì bởi những người có nhiều kinh nghiệm lập trình năng động vì vậy tôi giữ nó gần với mã Java bình thường trừ khi có một lý do chính đáng để sử dụng tính năng groovy nâng cao. Nghe có vẻ như nhóm của bạn nên tạo các tiêu chuẩn mã hóa để cố gắng giải thích khi sử dụng các tính năng cụ thể của Groovy.

Answer 4

Đây không phải lúc nào cũng là một ý kiến ​​phổ biến, nhưng tôi nghĩ rằng mã của bạn rõ ràng hơn và rõ ràng hơn, thì càng tốt.

Tôi không thích các cấu trúc mà để lại cho bạn đoán chỉ là những gì đang xảy ra ...

Tôi làm việc cho một năm trong Ruby và không thích điều đó chút nào. Tôi không nói rằng nó không có những nơi mà nó vượt trội, tôi chỉ nói rằng tôi thực sự muốn giữ cho mọi thứ sạch sẽ và rõ ràng và không cảm thấy rằng Ruby có đó là một mục tiêu.

Một điều tôi đã tìm ra chắc chắn - số lượng đánh máy bạn làm không tương đương với tốc độ phát triển tổng thể. Đúng là một mã cơ sở phức tạp với rất nhiều mã lặp lại làm cho việc phát triển rất chậm, nhưng chỉ đơn giản là giảm những gì bạn gõ mà không loại bỏ trùng lặp là vô ích, và gõ mã dài hơn, rõ ràng hơn, rõ ràng hơn sẽ nhanh hơn (trên chiều dài của dự án) so với cùng một mã được viết bằng một terse, ít ngôn ngữ chính thức hơn.

Nếu bạn không tin rằng việc nhập không liên quan đến tốc độ phát triển, lần sau bạn phát hành dự án đếm số dòng mã và chia cho số ngày đã dùng (bao gồm gỡ lỗi và thử nghiệm). Nói cách khác, có bao nhiêu mã được gõ một ngày. Bạn sẽ thấy kết quả là một số rất nhỏ - thực sự gõ mã là một phần rất nhỏ của bất kỳ dự án phần mềm nào.

Answer 5

YES

-

NO

Bạn có nhận ra không có câu trả lời thực sự cho câu hỏi này?

Answer 6

Có hai loại ngôn ngữ hướng đối tượng chi phối.

Các ngôn ngữ trong gia đình Simula 67, chẳng hạn như C++ và Java, ưu tiên các biến, trình biên dịch và trình liên kết tĩnh và phương thức vtables.

Các ngôn ngữ trong gia đình Smalltalk, chẳng hạn như Ruby, ưu tiên các biến được nhập động, diễn giải và thông báo thay vì các bảng con trỏ hàm.

Cả hai đều hướng đối tượng, nhưng rất khác nhau về khái niệm hướng đối tượng.