Ответ 1

да, вы можете использовать статический класс. например:

static class Global
{
    private static string _globalVar = "";

    public static string GlobalVar
    {
        get { return _globalVar; }
        set { _globalVar = value; }
    }
}

и для использования любого, где вы можете написать:

GlobalClass.GlobalVar = "any string value"

Ответ 2

Или вы можете поместить свои глобальные переменные в app.config

Ответ 3

Вы можете использовать статический класс или шаблон Singleton.

Ответ 4

Один способ,

Обозреватель решений > Ваш проект > Свойствa > Настройки. Настройки. Нажмите этот файл и добавьте определение своих настроек из среды IDE.

Доступ к ним через

Properties.Settings.Default.MySetting = "hello world";

Ответ 5

public static class MyGlobals
{
  public static string Global1 = "Hello";
  public static string Global2 = "World";
}

public class Foo
{

    private void Method1()
    {
       string example = MyGlobals.Global1;
       //etc
    }
}

Ответ 6

Если вы используете Visual С#, все, что вам нужно сделать, это добавить класс в Program.cs, наследующий форму, и изменить весь унаследованный класс из формы в ваш класс в каждой форме *.cs.

//Program.cs
public class Forms : Form
{
    //Declare your global valuables here.
}

//Form1.cs
public partial class Form1 : Forms    //Change from Form to Forms
{
    //...
}

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

Ответ 7

Они уже ответили, как использовать глобальную переменную.

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

Явный перевод текста на испанском языке:

Влияние изменения

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

Итак, у вас не может быть четкого представления о том, сколько объектов использует ваша глобальная переменная. И если вы хотите изменить что-то из глобальной переменной, например, значение каждого из своих возможных значений или его тип? Сколько классов или единиц компиляции повлияет на это изменение? Если сумма небольшая, возможно, стоит внести изменения. Если удар будет отличным, возможно, стоит искать другое решение.

Но каково влияние? Поскольку глобальную переменную можно использовать в любом месте кода, ее может быть очень сложно измерить.

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

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

Порядок уничтожения

Другой проблемой является порядок разрушения. Переменные всегда уничтожаются в обратном порядке их создания, являются ли они локальными или глобальными/статическими переменными (исключением являются примитивные типы, int, enum s и т.д., Которые никогда не уничтожаются, если они являются глобальными/статическими пока они не закончат программу).

Проблема заключается в том, что трудно знать порядок построения глобальных (или статических) переменных. В принципе, он неопределен.

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

Но если у вас есть более одного .cpp, каждый со своими собственными глобальными/статическими переменными, глобальный порядок построения неопределен. Разумеется, порядок в каждом модуле компиляции (в частности, каждый .cpp) соблюдается: если глобальная переменная A определена до B, A будет построена до B, но возможно что между A и B переменными другого .cpp инициализируются. Например, если у вас есть три единицы со следующими глобальными/статическими переменными:

Изображение1

В исполняемом файле он может быть создан в этом порядке (или в любом другом порядке, если относительный порядок соблюдается в каждом .cpp):

Изображение2

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

Скрытые зависимости и * тестовые примеры *

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

Представьте, что у вас есть платежная система, и вы хотите проверить ее, чтобы увидеть, как она работает, поскольку вам нужно внести изменения, а код - от другого человека (или вашего, но от нескольких лет назад). Вы открываете новый main, и вы вызываете соответствующую функцию вашего глобального объекта, которая предоставляет банковскую платежную услугу карточкой, и оказывается, что вы вводите свои данные, и они взимают с вас плату. Как в простой тесте я использовал производственную версию? Как я могу выполнить простой платеж?

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

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

Решение

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

Если существует слишком много глобальных объектов, и в требуемых им функциях слишком много параметров, вы всегда можете группировать "глобальные объекты" в класс, стиль * factory *, который строит и возвращает экземпляр от "глобального объекта" (имитируемого), который вы хотите, передав factory в качестве параметра для объектов, которым нужен глобальный объект в качестве зависимости.

Если вы перейдете в тестовый режим, вы всегда можете создать тестирование factory (которое возвращает разные версии тех же объектов) и передать его как параметр без необходимости изменять целевой класс.

Но всегда ли это плохо?

Не обязательно, что глобальные переменные могут быть полезны. Например, постоянные значения (значение PI). Будучи постоянной величиной, нет риска не знать ее значение в данной точке программы любым типом модификации из другого модуля. Кроме того, постоянные значения имеют тенденцию быть примитивными и вряд ли изменят их определение.

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

Другими могут быть неинтрузивные "глобальные" службы, такие как класс ведения журнала (сохранение того, что происходит в файле, которое обычно является необязательным и настраивается в программе и, следовательно, не влияет на ядерное поведение приложения) или std :: cout, std :: cin или std :: cerr, которые также являются глобальными объектами.

Любая другая вещь, даже если ее время жизни совпадает почти с тем, что в программе, всегда передавайте ее как параметр. Даже переменная может быть глобальной в модуле, только в ней без какого-либо другого доступа, но в любом случае зависимости всегда присутствуют в качестве параметров.

Ответа на этот вопрос: Peregring-lk