@staticmethod функція на рівні модуля

Це не про @staticmethodі @classmethod! Я знаю, як staticmethodпрацює. Що я хочу знати - це правильні випадки використання для @staticmethodфункцій на рівні модуля.

Я погуглив це питання, і, здається, є деяка загальна згода, що функції рівня модулів віддають перевагу статичним методам, оскільки це більше пітонічно. Статичні методи мають перевагу прив’язаності до свого класу, що може мати сенс, якщо тільки цей клас використовує його. Однак у Python функціональність, як правило, організовується модулем, не класом, тому зазвичай зробити його функцією модуля теж є сенс.

Статичні методи також можуть бути замінені підкласами, що є перевагою або недоліком залежно від того, як ви на це дивитесь. Хоча статичні методи, як правило, "функціонально чисті", тому це не може бути розумним, але іноді це може бути зручно (хоча це може бути одним із таких "зручних, але НІКОЛИ НЕ РОБИТИ" таких речей, лише досвід може навчити вас).

Чи є якісь загальні правила пальців для використання або функцій статичного методу, або рівня модуля? Які конкретні переваги чи недоліки вони мають (наприклад, майбутнє розширення, зовнішнє розширення, читабельність)? Якщо можливо, також наведіть приклад справи.

Технічно статичний метод і функція модуля поводяться майже однаково - в обох випадках вони працюють як стандартні функції, різницею є простір імен, де вони розміщені. Таким чином, рішення є більш важливим для технічного обслуговування / читабельності.

Як правило, я б застосував статичний метод, якщо деякі чи всі ці критерії виконуються:

• Вже є існуючий клас із звичайними методами
• Функція стосується об'єктів класу загалом, але не одного конкретного примірника
• Ви хочете мати можливість викликати метод так, ніби це нестатичний метод, можливо, тому що ви можете в майбутньому зробити метод нестатичним, не порушуючи код клієнта

Програма - це моделювання фрагмента реальності. Таким чином, це залежить від того, як ви сприймаєте реальність.

Функція представляє деяку діяльність. Чим більше активність загальна, тим більшою є тенденція до імітації діяльності за допомогою функції. Методи пов'язані з класами. Чим більше активність специфічна для класу, тим більше вона має тенденцію до імітації методом.

Подумайте про тригонометричні функції. Скажімо, sin()настільки відомий, що ви знаєте, що він відповідає кутам. Ви знаєте, що він хоче число float як вхід і повертає float. У будь-якому випадку може бути тип кутового типу даних, представлений класом, і .sin()аргумент без аргументу може бути звичайним методом, який працює з кутовим об'єктом, і .sin(x)з одним аргументом може бути статичний метод класу. Я міг би покластись, що більше людей думають, що краще зробити sin()просту функцію. Вони більше звикли.

Інша точка зору : Модуль нагадує екземпляр класу. Він має власні змінні члена та функції члена. У певному сенсі він реалізує однотонний зразок. Кожного разу, коли ви імпортуєте його з іншого модуля програми, ви отримуєте доступ до абсолютно таких самих змінних та функцій.

У мене є функція, яка буде брати частину ієрархії глибоких даних об'єкта як аргумент. Було б громіздко замість цього передати кілька аргументів, необхідних для того, щоб дійти до тієї частини ієрархії даних. Тому не майте підстав посилатися на себе або cls. Але функціонал буде використовуватися лише на частинах об'єктів певного класу. Тож мені здається класним методом.

Крім того, я вважаю за краще імпортувати ім’я класу ('з класу імпорту модуля', а не 'модуль імпорту'). Включення функції як статичного методу дає мені доступ до методу, а його написання як функція рівня модуля потребує іншого імпорту.