Я также удивлен количеством статических методов в игре, но почему бы и нет, если они работают нормально ...
На самом деле я не согласен с вашим учителем.
Если объект не имеет состояния (то есть глобальных переменных), но содержит только методы для примера, это не дает вам никаких преимуществ в использовании объекта, а не статических методов.
За исключением случаев, когда вы планируете добавить состояние позже (состояние, которое не должно быть общим), или если вы используете интерфейс и хотите иметь возможность легко переключать реализацию, проще использовать статические методы ...
Сам JDK, общие Apache или многие фреймворки включают статические методы:
- StringUtils
- Pattern.matches (регулярное выражение, вход)
----------
На самом деле, я думаю, вы задаетесь вопросом, что насчет таких классов, как JPA.java:
https://github.com/playframework/play/blob/master/framework/src/play/db/jpa/JPA.java
Они используют только статические методы и сохраняют статическое состояние.
Это может быть странно, но на самом деле для меня это немного похоже на использование синглтона, за исключением того, что методы используются в статическом контексте вместо объекта.
Основное отличие состоит в том, что вам не нужно каждый раз вызывать getInstance ().
Я думаю, что это было разработано так для удобства использования, потому что вызывать "getInstance" неудобно для пользователя, и было бы здорово иметь возможность легко получать сеанс везде (связанный с потоком) вместо того, чтобы внедрить sessionFactory везде с xml или автопроводка ...
Ваш профессор, возможно, говорит вам избегать использования статики, потому что это может быть опасно для вашего дизайна, если вы не используете их правильно. Но обратите внимание, что во многих случаях замена статических методов на одноэлементный не улучшает ваш дизайн. Даже если вы теперь вызовете методы для метода экземпляра, объекты все равно будут тесно связаны ...
Так что, возможно, следует избегать использования статики, за исключением случаев, когда вас не волнует жесткая связь.
В этом случае, когда вы вызываете методы JPA.xxx (), ваш код тесно связан с классом JPA игровой среды. Но я не думаю, что игра разработана так, чтобы вы могли легко переключаться с одного фреймворка на другой без каких-либо переделок ...
Это большая разница со спецификацией EJB3 или чем-то в этом роде: если методы менеджера сущностей EJB3, где статические, вы будете вынуждены тесно связать свой код с реализацией, вызывая HibernateEntityManager.xxx () или ToplinkEntityManager.xxx ().
В этом случае существует общий интерфейс (и мы не можем добавлять статические методы на интерфейсы).
----------
- Этот класс не является частью
Спецификация используется на других
рамки.
- класс JPA имеет только
одна реализация: сделанная
играть. И они, вероятно, не
планирую сделать второй.
- Таким образом,
тесная связь с этим классом игры,
пока вы используете Play Framework,
кажется, хорошо для меня.