Разве неправильно иметь статические и нестатические методы в том же классе?
Проблема и решение описаны здесь :
«ModuleNotFoundError» и «Module не может быть загружен» являются распространенными ошибками для функций Lambda в Python. Эти ошибки обычно связаны с неправильной структурой папок или правами доступа к файлу .zip пакета развертывания.
blockquote>Для дополнительных пакетов, вы посмотрели moviepy . Имейте в виду, что изменение пакета не решит вашу проблему. Вы должны включить модули пакета в лямбда-зип, следуя инструкциям выше.
5 ответов
Не совсем в обычном Java-программировании.
Но если вы много работаете с внедрением зависимостей, у вас, вероятно, мало или вообще нет статических методов. В таком контексте довольно часто бывает только несколько служебных классов со статическими методами и никаких других статических методов.
No, it's not wrong. For example, a common use is to have static factory methods in a class definition.
Я думаю, что можно создавать статические классы утилит , особенно когда вы не совсем уверены (пока), каким должен быть дизайн, потому что вы все еще изучаете проблемную область.
Статичность - это маркер «еще не разработан должным образом». Часто статического решения вполне достаточно; но иногда, по мере продвижения проекта, вы обнаруживаете, что вам действительно нужно переписать эту «целую часть», но у вас (на этом более позднем этапе) есть гораздо более полное понимание предметной области, и, следовательно, вы в состоянии действительно разработать «правильное решение» этих проблем.
Я думаю, что мы, программисты, несправедливо забиваем себе на «переделку» ». Вам необходимо выполнить работу, чтобы понять ее достаточно хорошо, чтобы выполнять работу должным образом. Я не вижу выхода из этой ловушки 22;
Я могу привести много примеров статики из основного API. java.lang.Math, java.util.Arrays, java.util.Collections. НО, пожалуйста, обратите внимание, что эти классы являются "классами утилит", которые существуют только для предоставления набора статических методов. ИМХО, наличие статических методов в «объекте с состоянием» просто напрашивается на рефакторинг.
I ' Бьюсь об заклад, что современные разработчики API хотели бы иметь возможность разделить Integer (и другие классы-оболочки) ... НО они хорошо и действительно застряли в том, что у них есть. Это само по себе предупреждение ... что static подразумевает final, и есть чертовски веская причина, по которой (в отличие от C ++) java-методы могут быть переопределены по умолчанию . Статический по своей сути более "связывающий", чем нестатический ... в этом трюке вы НЕ МОЖЕТЕ адаптировать реализации к различным ситуациям, контекстам и т. Д. И т. Д.
Ура. Кит.
В конце концов, вы НЕ МОЖЕТЕ адаптировать реализации к различным ситуациям, контекстам и т. д., и т. д.Ура. Кит.
В конце концов, вы НЕ МОЖЕТЕ адаптировать реализации к различным ситуациям, контекстам и т. д., и т. д.Ура. Кит.
Я считаю плохой идеей иметь статические и нестатические методы в одном классе с одним и тем же именем. Это может сбивать с толку. Я бы посоветовал попробовать изменить имена в этом случае.
Точно так же не создавайте методы с тем же именем, но с другим регистром, или методы с тем же именем, что и класс в том же классе. Оба являются законными и даже встречаются в JDK, но сбивают с толку IHMO.