Статические методы или нет? Глобальные переменные?

Question

Я хочу знать, какой путь более эффективен.

1. Нет глобальных переменных, передача переменных через параметры, все методы статические

2. Нет глобальных переменных, только статический метод main и создание объекта класса в main для доступа к методам

3. Использовать только глобальные переменные, используя только статический метод main, и создавать объект класса в main для доступа к методам

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

Пример структуры моего кода:

public class myClass {
   private int globalVariable;

   public static void main(String args[]) {
      myClass c;
      c.someMethod(); // Changes global variable from method
      System.out.println(someMethod); // Prints solution
   }

   public void someMethod() {...}
}

Answer 1

• Ни один класс не является островом.
• Серебряных пуль нет, по крайней мере, это очень верно в программировании.
• Преждевременная оптимизация - корень всего зла.
• В Java у нас нет глобальных переменных. У нас есть только переменные класса, переменные экземпляра и переменные метода.

[Изменить]

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

Сначала посмотрите на это, SO поток C # . Там люди также предлагают то же самое, то есть

• В C # нет глобальных переменных. Переменная всегда находится в локальной области. Фундаментальной единицей кода является класс, а внутри класса у вас есть поля, методы и свойства
• Я бы лично порекомендовал стереть из вашего словаря фразу "глобальная переменная" (это в разделе комментариев исходного вопроса)

Итак, поехали.

реторта: Классы имеют глобальную область, и, следовательно, все переменные класса имеют глобальную область. Следовательно, следует называть глобальным.

counter-реторта: Не все классы имеют глобальную область применения. Класс может быть package-private. Поэтому переменные static там не будут видны за пределами пакета. Следовательно, не следует называть глобальным. Кроме того, классы могут быть вложенными, таким образом, они также могут быть private и определенно могут иметь некоторые static переменные, но они не будут называться глобальными.

реторта: public классы имеют глобальную область, и, следовательно, все переменные класса имеют глобальную область.

встречная реторта: Не совсем так. Я хотел бы перенести предыдущий аргумент здесь, но на переменном уровне. Не имеет значения, является ли сам класс public. Переменные могут быть protected, package-private и private. Следовательно, static переменные не будут глобальными в этом случае.

Теперь, если вы хотите назвать переменную public static в классе public static как глобальную, тогда вызовите ее любым способом. Но учтите это, когда вы создаете новый ClassLoader (как дочерний элемент начальной загрузки ClassLoader) и загружаете уже загруженный класс. Тогда это приводит к «очень новой копии класса» - в комплекте с собственным новым набором static s. Очень "неглобальный", действительно. Тем не менее, мы не используем слово global в Java, потому что оно может сбить с толку, а затем нам нужно привести множество объяснений, чтобы все прояснить. Люди по праву любят объяснять особенность global переменных в Java с помощью static переменных. В этом нет проблем. Если у вас есть проблема / код на любом другом языке, который использует глобальные переменные, и вам нужно преобразовать этот код в Java, то, скорее всего, вы используете переменную static в качестве альтернативы.

Несколько примеров, которые я хотел бы привести здесь

1. Когда я запустил Java, инструкторам нравилось объяснять разницу между передачей переменных типа объекта и примитивных переменных. И они постоянно используют термин объекты pass-by-reference, тогда как примитивы pass-by-value. Студенты сочли это объяснение довольно запутанным. Итак, мы пришли к мысли, что все в Java передается по значению. И мы объясняем, что для объектов ссылки передаются по значению. Становится намного понятнее и проще.

2. Аналогично, существуют языки, которые поддерживают множественное наследование. Но Java, опять же, можно утверждать. Но люди склонны объяснять эту функцию, используя interface s. Они объясняют это классом, реализующим много интерфейсов, и называют это множественным наследованием. Это прекрасно. Но то, что класс, на самом деле, получает путем наследования ряда интерфейсов. Честно говоря, ничего. Зачем?

   .Поскольку все переменные в интерфейсах неявно public, final и static, что, очевидно, означает, что они принадлежат классу, и любой может получить к ним доступ.Теперь мы можем сказать, что, возможно, в интерфейсе будет inner class, тогда класс, реализующий интерфейс, будет иметь его.Но опять же это будет неявно static и будет принадлежать интерфейсу.Следовательно, все, что получит класс, это методы.И не забывайте только определение и контракт, который гласит: «класс, реализующий этот интерфейс, должен обеспечить реализацию всех методов или объявить себя abstract».Следовательно, этот класс получит только обязанности и ничего особенного.Но это решает наши проблемы блестящим образом.

Итог

Поэтому мы говорим

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

Теперь мне нравится посещать еще несколько мест

• Java не поддерживает глобальные, универсально доступные переменные.Вы можете получить те же самые эффекты с классами, которые имеют статические переменные [Ref]
• Однако extern в ObjectiveC не является альтернативой статической переменной класса в Java,на самом деле это больше похоже на глобальную переменную ... так что используйте с осторожностью. [Ref]
• Вместо глобальных переменных, как в C / C ++, Java позволяет объявить переменные в классе статическими [Ref]

Все это выводит одну и ту же идею.То есть Java не поддерживает глобальные переменные.

Черт, я так много писал.Извините, ребята.

Answer 2

Я думаю, что это было решено еще в 1956 и 1958 годах, когда люди изобрели Лисп и ALGOL58 и размышляли о модульности , ссылочной прозрачности и структуре звукового кода как средства решения непроходимых спагетти. код, который опирается на глобальные переменные (и которые, как правило, демонстрируют программный эквивалент принципа неопределенности Гейзенберга.)

Я имею в виду серьезно, это 2011 год, и мы все еще задаемся вопросом, использовать ли глобальные переменные над инкапсулированными полями или передачу параметров для цитат-к-цитат эффективность . Я имею в виду, серьезно.

Я могу показаться высокомерным (так и быть), но я скажу так:

Я могу понять некоторые пробелы, в которых вы должны делать какие-то глобальные переменные (например, встроенные платформы с очень ограниченными ресурсами). Я могу понять, если человек, который только начинает в CS (скажем, новичок) спрашивает это.

Но если кто-то выше уровня первокурсника (не говоря уже о том, кто занимается кодированием для жизни и не кодирует в наиболее бесплодной среде), просит или даже дистанционно думает об этом как о приемлемой вещи, следует серьезно пересмотреть вопрос о возвращении к основы (или пересмотреть эту профессию - у нас уже слишком много дерьмового кода).

Краткий и краткий ответ: нет, это не имеет смысла. Там нет заметных игр. Это того не стоит. Это приводит к дерьмовому коду. И все это известно уже 50 лет.

Answer 3

Производительность не имеет значения. Вы хотите, чтобы это было так легко читать, насколько это возможно.

Я бы сделал 2 столько, сколько ты сможешь. Когда вам действительно нужны константы и статика, создайте константы и статику.

Например, нулевая безопасная обрезка делает хороший статический метод. Новое повышение StringTrimmer глупо. Помещать, если ноль, тогда x иначе z в 1000 других глупо.