@staticmethod против функции уровня модуля

Это не про @staticmethodа @classmethod! Я знаю, как staticmethodработает. То, что я хочу знать, - это правильные варианты использования для @staticmethodфункции уровня модуля.

Я погуглил этот вопрос, и кажется, что есть общее согласие, что функции уровня модуля предпочтительнее статических методов, потому что они более питонны. Преимущество статических методов заключается в том, что они привязаны к своему классу, что может иметь смысл, если только этот класс использует его. Однако в Python функциональность обычно организована модулем, а не классом, поэтому обычно имеет смысл сделать его функцией модуля.

Статические методы также могут быть переопределены подклассами, что является преимуществом или недостатком в зависимости от того, как вы на это смотрите. Хотя статические методы обычно являются «функционально чистыми», поэтому их переопределение может быть неумным, но иногда это может быть удобно (хотя это может быть одним из тех «удобных, но НИКОГДА НЕ ДЕЛАЮЩИХ» вещей, которым только опыт может научить).

Существуют ли общие правила использования статического метода или функций уровня модуля? Какие конкретные преимущества или недостатки у них есть (например, будущее расширение, внешнее расширение, удобочитаемость)? Если возможно, также приведите пример.

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

Как правило, я бы использовал статический метод, если выполнены некоторые или все эти критерии:

• Уже существует класс с обычными методами
• Функция относится к объектам класса в целом, но не к одному конкретному экземпляру.
• Вы хотите иметь возможность вызывать метод, как если бы он был нестатическим, возможно, потому, что вы можете сделать метод нестатичным в будущем, не нарушая клиентский код

Программа - это симуляция кусочка реальности. Таким образом, это зависит от того, как вы воспринимаете реальность.

Функция представляет собой некоторую активность. Чем больше общее действие, тем больше тенденция имитировать действие с помощью функции. Методы привязаны к классам. Чем больше активность является специфической для класса, тем больше она имитируется методом.

Подумайте о тригонометрических функциях. Скажем так, sin()он настолько известен, что вы знаете, что он подходит под углами. Вы знаете, что он хочет ввести число с плавающей точкой и возвращает число с плавающей точкой. В любом случае, может быть тип данных угла, представленный классом, а .sin()аргумент без может быть обычным методом, который работает с объектом угла, а .sin(x)с одним аргументом может быть статическим методом класса. Могу поспорить, что все больше людей думают, что лучше сделать sin()простую функцию. Они более привыкли.

Другая точка зрения : модуль похож на экземпляр класса. Он имеет свои собственные переменные-члены и функции-члены. В каком-то смысле он реализует шаблон синглтона. Всякий раз, когда вы импортируете его из другого модуля приложения, вы получаете доступ к точно таким же переменным и функциям.

У меня есть функция, которая будет принимать некоторую часть глубокой иерархии данных объекта в качестве аргумента. Было бы неудобно вместо этого передать несколько аргументов, необходимых для доступа к этой части иерархии данных. Так что нет причин ссылаться на себя или кл. Но функциональность будет использоваться только на части объектов определенного класса. Так что мне кажется, что это метод класса.

Кроме того, я предпочитаю импортировать имя класса («из класса импорта модуля», а не «модуля импорта»). Включение функции в качестве статического метода дает мне доступ к методу, в то время как написание его как функции уровня модуля потребует другого импорта.