Здравствуйте, igna, Вы писали:

_FR>>Если по-простому: не заводить таковых. Как? В функции Main создаются необходимые локальные переменные (обычно, одна-единственная). У неё вызывается какой-нить Run. Далее: все данные — это поля (не статические) этой переменной.

I>Соображение первое: Языки программирования могли бы позволять явно специфицировать функции/методы как не имеющие доступа к глобальным переменным, и таким образом помочь описанному выше стилю программирования:

Зачем? достаточно выбрасить все ненужные глобальные переменные. А зачем они ещё нужны, если не для того, что бы ими кто-то пользовался.

I>Соображение второе: Всегда есть возможность передавать эту локальную определенную в Main переменную в каждую функцию программы, причем этот подход наверняка будет кем-либо с гордостью использован, если Singleton вдруг станет не модным.

Совсем ничего не понял

Здравствуйте, _FRED_, Вы писали:

_FR>Это всё, думаю, тебе известно Ты какие-то конкретные трудности видишь?

Прозрачности нет. Постоянно нужно таскать с собой те переменные, которые непосредственно тебе могут и не понадобиться, а понадобятся тем классам, которые ты будешь создавать. ИМХО, это приводит к чрезмерной связности объектов. Нехорошо это.

Здравствуйте, _FRED_, Вы писали:

_FR>Совсем ничего не понял

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

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>У меня в системе синглетоном ещё логгер реализован.

I>Чем это в твоем случае лучше чем статическими методами?

Тем, что синглтон реализован один раз генериком, а Logger — обычный класс, реализующий интерфейс.

Здравствуйте, igna, Вы писали:

_FR>>Совсем ничего не понял

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

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

Здравствуйте, _FRED_, Вы писали:

_FR>Зачем? достаточно выбрасить все ненужные глобальные переменные.

Если выбросить все ненужные, то возможно останутся нужные. А чистая функция не должна использовать никаких.

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

Здравствуйте, Aen Sidhe, Вы писали:

AS>Тем, что синглтон реализован один раз генериком, а Logger — обычный класс, реализующий интерфейс.

А зачем нужен этот интерфейс?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Тем, что синглтон реализован один раз генериком, а Logger — обычный класс, реализующий интерфейс.

I>А зачем нужен этот интерфейс?

Всего лишь для того, чтобы не зависеть от конкретной реализации логгера. В данный момент я использую log4net в качестве бэка. Когда найду что-нибудь лучше — мне надо будет всего лишь заменить реализацию.

Здравствуйте, Aen Sidhe, Вы писали:

AS>Всего лишь для того, чтобы не зависеть от конкретной реализации логгера. В данный момент я использую log4net в качестве бэка. Когда найду что-нибудь лучше — мне надо будет всего лишь заменить реализацию.

Ну а в случае статического класса кто то же самое сделать мешает?

Здравствуйте, Lloyd, Вы писали:

_FR>>Это всё, думаю, тебе известно Ты какие-то конкретные трудности видишь?

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

Наоборот, получается, что всё прозрачно: каждый уровень видит, что нужно связанным с ним. А прозрачность (кажущаяся) — это как раз к синглетонам — фиг знает, что там в них используется.
И чрезмерная такая прозрачность — да, плохо. Небольшая — часто не мешает и даже наоборот.

Таскать, обычно, нужно одну переменную Application (в простом случае) или Container\Builder, через которую можно получить всё остальное. Второй приём — многие "синглетоны" заменятся обычными классами, которые можно на каждый чих (на каждую логический чих) создавать заново. Просто некоторые "оптимизаторы" думают — ага! для этого типа можно применить паттерн Синглетон! и всё будет здорово! тогда как наоборот, они могут отказаться от него и создавать нужные классы каждый раз по-требованию.

L>ИМХО, это приводит к чрезмерной связности объектов. Нехорошо это.

Не хорошо. Когда становится видно, что появилась "чрезмерная связанность", надо брать в руки IoC и таскать придётся один контейнер. Или, даже, не так. Если есть система объектов, то один знает про другой, другой про третий и т.д. тогда кто-то может и не иметь свой контейнер, а пользоваться контейнером какого-то объекта, про который он знает и у которого контейнер есть: получается не обяхательно везде его, контейнер, протаскивать.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Всего лишь для того, чтобы не зависеть от конкретной реализации логгера. В данный момент я использую log4net в качестве бэка. Когда найду что-нибудь лучше — мне надо будет всего лишь заменить реализацию.

I>Ну а в случае статического класса кто то же самое сделать мешает?

Вероятно то, что мне не придётся "переписывать код", а "дописывать его".

Здравствуйте, Aen Sidhe, Вы писали:

AS>Вероятно то, что мне не придётся "переписывать код", а "дописывать его".

У тебя не только интерфейс, но и независимый от log4net абстрактный класс есть?

Здравствуйте, _FRED_, Вы писали:

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

_FR>Наоборот, получается, что всё прозрачно: каждый уровень видит, что нужно связанным с ним. А прозрачность (кажущаяся) — это как раз к синглетонам — фиг знает, что там в них используется.
_FR>И чрезмерная такая прозрачность — да, плохо. Небольшая — часто не мешает и даже наоборот.

Я и не ратую за чрезмерное использование синглтонов. Один глобальный ServiceLocator — наш выбор.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Вероятно то, что мне не придётся "переписывать код", а "дописывать его".

I>У тебя не только интерфейс, но и независимый от log4net абстрактный класс есть?

Есть. NullLogger. Шлёт всё в /dev/null.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, Lloyd, Вы писали:

_FR>>>Это всё, думаю, тебе известно Ты какие-то конкретные трудности видишь?

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

_FR>Наоборот, получается, что всё прозрачно: каждый уровень видит, что нужно связанным с ним. А прозрачность (кажущаяся) — это как раз к синглетонам — фиг знает, что там в них используется.
_FR>И чрезмерная такая прозрачность — да, плохо. Небольшая — часто не мешает и даже наоборот.

_FR>Таскать, обычно, нужно одну переменную Application (в простом случае) или Container\Builder, через которую можно получить всё остальное. Второй приём — многие "синглетоны" заменятся обычными классами, которые можно на каждый чих (на каждую логический чих) создавать заново. Просто некоторые "оптимизаторы" думают — ага! для этого типа можно применить паттерн Синглетон! и всё будет здорово! тогда как наоборот, они могут отказаться от него и создавать нужные классы каждый раз по-требованию.


А тут для этого используется контекст. И, вроде бы, совсем неплохо

здесь

Здравствуйте, _FRED_, Вы писали:

_FR>Таскать, обычно, нужно одну переменную Application (в простом случае) или Container\Builder, через которую можно получить всё остальное.

IMHO таскать нужно только то, что нужно, а не все. "Container\Builder, через которую можно получить всё остальное" звучит устрашающе, и как я уже писал, для кого-то логическим завершением этой идей может стать передача Container\Builder-а каждому методу.

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

Здравствуйте, Aen Sidhe, Вы писали:

AS>Есть. NullLogger. Шлёт всё в /dev/null.

Понятно. Тем не менее можно иметь и аналогичные методам NullLogger-а статические методы и использовать их при реализации методов зависимых от log4net. И тогда тоже придётся не "переписывать", а "дописывать".

Здравствуйте, EyfelFenk, Вы писали:

EF>Народ подскжаите как в C# создать Singleton класс?

В свете развернувшейся дискуссии, рекомендую попробовать вот эту штуку. Будет полезна, очень.

Здравствуйте, drol, Вы писали:

D>В свете развернувшейся дискуссии, рекомендую попробовать вот эту штуку. Будет полезна, очень.

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

Здравствуйте, Lloyd, Вы писали:

L>А ты вместо того, чтобы советовать, что лучше, а что нет, лучше присоединяйся к дисскусии.
L>Или ты тоже предлагаешь всюду за собой таскать контейнер?

Если при разработке действительно возникает потребность в конструкциях по типу синглтона, то значит сложность софта вполне себе доросла до использования контейнера. И я предлагаю взять вполне конкретную вышеуказанную библиотеку. Она достаточно легковесная, а по части использования — проще и удобнее просто некуда.