@staticmethod so với chức năng cấp mô-đun

Đây không phải là về @staticmethodvà @classmethod! Tôi biết làm thế nào staticmethodhoạt động. Những gì tôi muốn biết là các trường hợp sử dụng thích hợp cho @staticmethodso với chức năng cấp mô-đun.

Tôi đã đưa ra câu hỏi này và có vẻ như có một số thỏa thuận chung rằng các hàm cấp mô-đun được ưa thích hơn các phương thức tĩnh vì nó mang tính pythonic hơn. Các phương thức tĩnh có lợi thế là bị ràng buộc với lớp của nó, điều này có thể có ý nghĩa nếu chỉ có lớp đó sử dụng nó. Tuy nhiên, trong chức năng Python thường được tổ chức bởi mô-đun chứ không phải lớp, do đó, thường làm cho nó trở thành chức năng mô-đun.

Các phương thức tĩnh cũng có thể bị ghi đè bởi các lớp con, đây là một lợi thế hoặc bất lợi tùy thuộc vào cách bạn nhìn vào nó. Mặc dù, các phương thức tĩnh thường là "thuần túy về mặt chức năng" nên việc ghi đè nó có thể không thông minh, nhưng đôi khi nó có thể thuận tiện (mặc dù đây có thể là một trong những điều "tiện lợi, nhưng KHÔNG BAO GIỜ NÓ" chỉ có kinh nghiệm mới có thể dạy bạn).

Có bất kỳ quy tắc chung nào cho việc sử dụng các hàm cấp độ tĩnh hoặc mô-đun không? Những lợi thế hoặc bất lợi cụ thể nào họ có (ví dụ như mở rộng trong tương lai, mở rộng bên ngoài, khả năng đọc)? Nếu có thể, cũng cung cấp một ví dụ trường hợp.

Về mặt kỹ thuật, một phương thức tĩnh và một chức năng mô-đun hoạt động khá giống nhau - Trong cả hai trường hợp chúng hoạt động giống như các hàm tiêu chuẩn, sự khác biệt là không gian tên nơi chúng được đặt. Vì vậy, quyết định là một trong những khả năng duy trì / dễ đọc.

Nói chung tôi sẽ sử dụng một phương thức tĩnh nếu một số hoặc tất cả các tiêu chí này được đáp ứng:

• Đã có một lớp hiện có với các phương thức bình thường
• Hàm nói chung liên quan đến các đối tượng của lớp, nhưng không phải là một trường hợp cụ thể
• Bạn muốn có thể gọi phương thức như thể đó là phương thức không tĩnh, có thể vì bạn có thể muốn làm cho phương thức không tĩnh trong tương lai mà không phá vỡ mã máy khách

Một chương trình là một mô phỏng của một phần của thực tế. Bằng cách này, nó phụ thuộc vào cách bạn nhìn nhận thực tế.

Một chức năng đại diện cho một số hoạt động. Hoạt động càng chung chung thì càng có xu hướng mô phỏng hoạt động với một chức năng. Các phương thức được ràng buộc với các lớp. Hoạt động càng cụ thể đối với lớp, nó càng có xu hướng được mô phỏng theo một phương thức.

Hãy suy nghĩ về các hàm lượng giác. Nói, sin()nổi tiếng đến mức bạn biết nó phù hợp với các góc. Bạn biết rằng nó muốn một số float làm đầu vào và trả về float. Dù sao, có thể có một kiểu dữ liệu góc được đại diện bởi một lớp và .sin()đối số không có thể là một phương thức bình thường hoạt động với đối tượng góc và .sin(x)với một đối số duy nhất có thể là một phương thức tĩnh của lớp. Tôi có thể đặt cược rằng nhiều người nghĩ rằng tốt hơn là tạo ra sin()một chức năng đơn giản. Chúng được sử dụng nhiều hơn.

Một quan điểm khác : Một mô-đun giống như một thể hiện của lớp. Nó có các biến thành viên riêng và các hàm thành viên. Trong một số ý nghĩa, nó thực hiện một mô hình singleton. Bất cứ khi nào bạn nhập nó từ một mô-đun khác của ứng dụng, bạn sẽ có quyền truy cập vào chính xác các biến và chức năng tương tự.

Tôi có một hàm sẽ lấy một phần của hệ thống phân cấp dữ liệu sâu của một đối tượng làm đối số. Thay vào đó, sẽ rất khó khăn khi chuyển qua một số đối số cần thiết để đến phần đó của hệ thống phân cấp dữ liệu. Vì vậy, không có lý do để tham khảo bản thân hoặc cls. Nhưng chức năng sẽ chỉ được sử dụng trên các phần của các đối tượng của một lớp cụ thể. Vì vậy, nó có vẻ là một phương pháp lớp học với tôi.

Hơn nữa, tôi thích nhập tên lớp ('từ lớp nhập mô-đun' hơn là 'mô-đun nhập'). Việc bao gồm hàm như một phương thức tĩnh cho phép tôi truy cập vào phương thức trong khi viết nó dưới dạng hàm cấp mô-đun sẽ yêu cầu nhập khác.