Im a static fobic

Question

Ну, из всего, что я прочитал о том, как могут быть злые статические переменные, я стал статическим фобией. Я так боюсь поставить статическую переменную в один большой проект, потому что чувствую, что могу сожалеть об этом, хотя это сделает код проще. Я никогда не понимал, когда все в порядке использовать статику, поэтому я стараюсь никогда их не использовать. Я развиваю эту большую игру, и статический entityManager был бы настолько полезен, вместо этого я закончил тем, что передал экземпляр entityManager всем классам, которые в нем нуждаются, но иногда его так сложно передать. И было бы так просто сделать EntityManager.addEntity(Entity);

Я знаю, что есть такие темы, как «Когда все в порядке использовать статические?» но, похоже, нет простого способа объяснить это простым способом понять.

Может ли кто-нибудь сказать мне легко-английским способом, когда все в порядке использовать статические переменные?

english не является моим основным языком, поэтому, пожалуйста, имейте это в виду.

Answer 1

1) это совершенно нормально, чтобы использовать статические экземпляры с окончательным ключевым словом, как только для чтения константа

2) если вы хотите одноэлементные услуги, которые доступны в различных компонентах, лучше использовать рамки для инъекций зависимостей, как Spring DI, CDI или Guice управлять им

Answer 2

static отлично подходит для лиц без, чистых методов, как String.format()

static отлично подходит для констант, например:

public static final double PI = 3.14159; 

static отлично подходит для частных полей, для которых по логическому определению может быть только одно значение, например список значений в enum (и общедоступные методы, используемые для доступа к этим частным полям).

В то время как у вас обычно только один EntityManager в приложении, нет ничего плохого в том, что у него больше одного. У вас может быть 3 или 3 миллиона. Поскольку нет строгого одного менеджера, он не должен быть статическим. Передача его - правильный способ справиться с этим.

Answer 3

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

Теперь, если вам кажется, что слишком много работы для вас, чтобы передать этого менеджера по всему, поверьте, он приносит большую гибкость. С другой стороны, если слишком много менеджеров, которые проходят, пересматривают ваши классы и, возможно, разделяют их на более мелкие части. В идеальном случае каждый класс должен нести ответственность только от одной вещи.