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

__>>Так что смысл было делать синглтоны для меня до сих пор неясен. Я ищу ПРИЧИНУ присутствия синглтонов в _моём_ коде.

iT>Может к ним у вас там удаленный доступ имеется (Remoting)?

К синглотонам — нет.

Но!!! Я нашел удивительный комент с родителю этих всех синглтонов: "Все синглтоны должны быть полиморфными классами".
Но на мой вопрос "почему" ответа нет.

Самый очевидный для меня резон написания синглетона на месте статического тулкита — это тесты. Выделив интерфейс синглетона затем его инстанс переменную легко подменять на mock реализацию этого интерфейса в тестах. (вариант — просто наследовать класс и переопрделить mock реализацию нужных методов, но судя по вашему примеру кода это не тот случай). Кроме того синглетон позволяет легко добавлять логику в конструктор — ну например инициализацию кэша. Это как задел на будущее. Да, самый очевидный ответ — ребят просто перло писать приватные конструкторы и никакой мысли у них не было.

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

L>Судя по описанию некто прочитал книжку по паттернам, а ума не прибавилось.

Я бы даже сказал, что кого-то хватило лишь на первые 15-ть страниц книги по паттернам

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

__>>>Спасибо за наводку. Но ни то ни другое у нас не используется. Так что вопрос остаётся открытым. Зачем они каждый класс с простым набором методов пихают в синглтон?

N>>Может быть, задел на будущее. А может быть, привычка... Откуда ж я знаю, что у вас имели в виду?
N>>Документация по архитектуре сохранилась?

__>Кое-что есть, но именно этого там нет. Буду искать встречи с архитекторами.

Нашел одного из них.

Говорит что эти лэеры были сделаны не статическими, чтобы можно былообрабатывать в каждом из них ошибки не стандартными методами, а по-своему.

Т.е. где-то внутри

static MyClass Instace { get; }

должен был быть свой обработчик ошибок. Хотя его нигде нет. Оставили "на потом" и отказались в конце-концов.


Всем спасибо за участие.

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


__>>>И потом юзание только через MyClass.Instance.SomeMethod()
K>>хм ... стандартная реализация сингетона, было бы неплохо добавить потоко безопастность, но в целом нормально ....
K>>так а "переменных" статических что то я не вижу ... Кстати, под переменными вы имеете ввиду поля? ...
K>>ничто не мешает добавить добавлять не статические поля,свойства,методы и др. ...
K>>Что Вас инетерсует, Вам не понятна реализация синглетона или что?

__>Меня интересует, почему те, кто начинал писать это дело, ВЕЗДЕ юзают синглотны, где достаточно было обычных статик функций?
__>И таких вот бесполезных синглтонов сотни!
Ну это вопросы к разработчикам ... вообще Синглетон нужен, когда необходимо отслеживать состояние объекта ...

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

__>Каждый класс, который представляет собой набор функций (business/application logic layer), юзается через синглтоны! Почему? Ведь ни один из них не содержит переменных (кроме статиковых). Есть тому разумная причина для .Нет платформы?

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

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

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

__>>Каждый класс, который представляет собой набор функций (business/application logic layer), юзается через синглтоны! Почему? Ведь ни один из них не содержит переменных (кроме статиковых). Есть тому разумная причина для .Нет платформы?

_FR>Тут я вижу два момента. Класс и синглетон. С одиночкой авторы-выдумщики сильно промахнулись: никакого оправдания тому, что бы делать класс без состояния одиночкой быть не может. Я такие классы делаю с конструктором по-умолчанию и создаю экземпляры каждый раз перед использованием.

Вот этот абзац не понял.


_FR>Так же в вашей ситуации можно задуматься: а зачем нам методы делать экземплярными и не сделать ли их статическими? Вот это совсем не обязательно. Как уже сказали, возможно, необходимо пользоваться ремотингом или каким-то ещё механизмом перехвата, который может работать только с методами экземпляра.

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

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

__>Всем добр. [время суток].

__>Вот есть тут у нас код, пИсаный пару лет назад.
__>Каждый класс, который представляет собой набор функций (business/application logic layer), юзается через синглтоны! Почему? Ведь ни один из них не содержит переменных (кроме статиковых). Есть тому разумная причина для .Нет платформы?
Есть одна. Если для конструирования синглтона нужно что-то нетривиальное, то лучше не делать его статическим.
Потому, что статический конструктор вызывается не более одного раза; если возникло исключение — всё, пипец, все обращения к этому классу в дальнейшем будут вызывать тот же exception. Так что если, к примеру, при инициализации хочется зачитать какой-нибудь файл, то статик — это грабли. Неудачно заблокированный на секунду файл положит приложение до рестарта домена.

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

__>>>Каждый класс, который представляет собой набор функций (business/application logic layer), юзается через синглтоны! Почему? Ведь ни один из них не содержит переменных (кроме статиковых). Есть тому разумная причина для .Нет платформы?

_FR>>Тут я вижу два момента. Класс и синглетон. С одиночкой авторы-выдумщики сильно промахнулись: никакого оправдания тому, что бы делать класс без состояния одиночкой быть не может. Я такие классы делаю с конструктором по-умолчанию и создаю экземпляры каждый раз перед использованием.

__>Вот этот абзац не понял.

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

__>До архитекторов сего дела удалось достучатся. Говорит что синглтоны нужны были для того, чтобы нестандартно обрабатывать в каждом из таких классов ошибки. Всё.

А они могут показать связь между реализацией синглетона и обработкой исключений? Я её не вижу

__>А т.к. никто в этих классах у нас ошибки не обрабатывает, то эти все синглтоны получаются рудиментом.

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