Глобальные переменные v Настройки в C # - PullRequest
6 голосов
/ 29 октября 2009

Я читал в разных местах, что наличие переменных с глобальной областью видимости, то есть общедоступного статического класса со статическими членами, считается противоречащим философии ОО и не является хорошим дизайном. (Например, я видел комментарии в виде: «Если вы используете глобальный, вы не делаете это правильно.» Или слова на этот счет.)

Но если вы используете механизм настроек, предоставляемый Visual Studio, например, «Settings.Default.MySetting» и т. Д., Это доступно по всему приложению, так чем же оно отличается от использования открытого статического класса?

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

Глобальные переменные просто НАСТОЛЬКО полезны, (модуль VB, кто-нибудь?), Но я пытаюсь научить себя, как правильно делать эту ОО-малярию, поэтому, если глобальные переменные плохо пахнут с ОО-точки зрения, что альтернатива?

Меня особенно интересует мнение людей об использовании функции «Настройки». Считается ли это хорошим дизайном ОО?

Спасибо за любые комментарии.

Ответы [ 5 ]

15 голосов
/ 29 октября 2009

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

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

2 голосов
/ 29 октября 2009

В C # вам будет трудно идти против хорошего дизайна ОО, потому что вы не можете уйти от ОО. Это не то же самое, что C ++, где вы можете смешивать и сопоставлять структурированное ОО-программирование - область, в которой часто встречаются подобные аргументы. Статические члены класса OO. То же самое относится и к сгенерированным Microsoft настройкам, поскольку генерация кода создает для них ОО-инкапсуляцию или, по крайней мере, «объектный контейнер» вокруг них. Таким образом, они никогда не являются глобальными переменными, потому что их нет в C # - они просто статические члены в классах - ничего такого, что не является OO.

Если аргумент о синглтоне против статических членов, то он противопоставляет один аргумент OO другому аргументу OO.

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

1 голос
/ 29 октября 2009

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

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

1 голос
/ 29 октября 2009

Публичный статический класс или член не всегда плохая идея (даже если это не совсем ОО). Многие хорошие ОО-проекты используют открытый статический член для таких вещей, как регистраторы или настройки (как вы указали). Хорошим примером того, как это сделать в ОО-режиме, является Static Gateway .

0 голосов
/ 29 октября 2009

Механизм настроек ... хм ...

Я смотрю на них в основном как на часть окружающей среды. Вроде ОС или Время, но для приложения. На самом деле они не являются «переменными», как вы бы объявили во время INIT.

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

В конце концов, по мере взросления приложений подобные вещи в конечном итоге оборачиваются объектами. Мое правило: всякий раз, когда я начинаю думать: «Нет, это слишком просто, слишком атомарно и не требует объекта ...» - это мой ключ, чтобы сделать его объектом.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...