Класс Java, который имеет 90% статических членов. Хорошая практика или что?

Question

Мне 14 лет, и я изучаю Java около 4/5 месяцев.Я пишу игру, которая теперь называется Super Mario Winshine, и я хотел знать, будет ли хорошей практикой иметь класс, который в основном состоит из статических переменных.

Класс, в котором хранится вся информация об уровне / мире игры.Поскольку мне нужна только одна версия этого класса, и многие другие классы будут использовать ее, я решил сделать все переменные статическими.Это хорошая практика?

Я учел тот факт, что я могу сохранить переменные "нестатическими" и просто клонировать основной объект, который я использую для этого класса, но я подумал, что скорее пожертвую "OO" дляпамять в этом случае.

Answer 1

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

По моему опыту, 90% времени, когда маркетинг говорит: «О, не волнуйтесь, естьбудет только одно Приложение / Окно / База данных / Пользователь ", они не правы.

ДОБАВЛЕНО

Я бы также избегал использования истинного шаблона Singleton с World.getInstance () и т. д. Это дляредкие случаи, когда является существенным требованием , чтобы было только одно из чего-то.В вашем случае вы используете это как удобство, а не требование.

Не существует идеального исправления, YMMV, но я бы рассмотрел один статический метод, что-то вроде

   World World.getWorld(String name)

, а затем вы вызываете реальные (нестатические) методы в Мире, которыевозвращаетсяДля V1 вашей программы позвольте null означать «мир по умолчанию».

Некоторые могут поместить этот метод в класс с именем WorldManager или, возможно, показывая мой возраст, более умное имя, такое как Amber.: -)

Answer 2

Все зависит от ваших методов и классов.Нет проблем в определении служебных методов как статических методов в классе.Нет необходимости делать его единственным, как предлагают другие.Посмотрите на класс Math из пакета java.lang.У него много полезных методов, но это не синглтон.

Также проверьте функциональность статического импорта .При использовании этого вам не нужно квалифицировать вызовы методов с именем класса.

Answer 3

Я бы сказал, что это определенно не очень хорошая практика.

Я не видел ваш код, но наличие нескольких статических переменных в классе, к которому другие классы имеют свободный доступ, похоже, указывает на то, что вы на самом деле не используетеобъектная ориентация / классы, но больше просто написание процедурного кода на Java.Классы обычно должны инкапсулировать / скрывать все свои переменные - статические или нет - от доступа других классов, чтобы другие классы не зависели от того, как класс реализован.

Статическая часть также вызывает проблемы с работой потоков(глобальные переменные трудно заблокировать хорошим способом, чтобы ничего не блокировалось) и с модульным тестированием (насмешка практически невозможна)

Я также согласен с другими авторами, если вам нужны "глобальные переменные", вхотя бы сделай их одиночками.Это позволяет вам позже легче изменить стратегию и не привязывает вас к одному миру.

Редактировать: Я определенно не защищаю одиночные игры как хороший образец здесь, если кто-то читает это так, но это действительно решает некоторые проблемысо статическими переменными, особеннопо сравнению с тестированием / макетом по сравнению только со статикой, поэтому я бы сказал, что это очень легкий оттенок серого :) Это также шаблон, который легче постепенно заменить на лучшие шаблоны, например, с помощью контейнера IoC.

Answer 4

Ну, то, что вы делаете, это определенно вариант.Или вы можете использовать одноэлементный шаблон:

public class World {
   private static World instance = new World();

   private World() {
   }

   public static World getInstance() {
       return instance;
   }
}

Теперь просто используйте World.getInstance() везде, чтобы иметь уникальный объект этого типа для приложения.

Answer 5

Я не уверен, что вы на самом деле говорите из своего короткого описания, поэтому я попробую это:

public class Level {
  static List<Mushroom> mushrooms;
  static List<Coin> coins;
  ...
}

Это вы описывали?

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

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

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

Answer 6

Я думаю, что все в порядке, если вам не нужно ничего более сложного, иными словами, статические поля в порядке, если разные объекты (включая подклассы, если таковые будут) не нуждаются в разных значениях.

Вы сами пишете код, рефакторинг легко с современными инструментами, я говорю, не исправляйте его, пока он не сломан, и сосредоточьтесь на алгоритмических аспектах вашего проекта.

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

Но ясно, что это не проблема сегодняшнего дня.До тех пор, наслаждайтесь!

Answer 7

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

Также вы должны принять во внимание назначение static членов, которое состоит в том, чтобы быть членом класса и «действовать» в / с классом, а не его экземпляром. Например, статический метод в синглтоне возвращает либо новый экземпляр класса, если он еще не существует, либо возвращает экземпляр, а поскольку метод является static, вы не создаете экземпляр new. Этот , вероятно, стоит прочитать, потому что он может несколько запутать при определении правильного использования static членов