Синглтон с финализатором, но не с IDisposable

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

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

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

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

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

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

Другими словами, вы можете создавать сценарии, в которых для синглтонов логично иметь IDisposable.

Пока ваш финализатор не вызывает методы (например, Dispose) для любых других управляемых объектов, все должно быть в порядке. Просто помните, что порядок завершения не детерминирован. То есть, если ваш одноэлементный объект Foo содержит ссылку на объект Bar, который требует удаления, вы не можете надежно написать:

~Foo()
{
    Bar.Dispose();
}

Сборщик мусора, возможно, уже собрал Bar.

Рискуя попасть в кучу OO goo (т.е. начать войну), одна из альтернатив использования синглтона - использование статического класса.

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

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

Помимо применимости синглтона к любой конкретной ситуации,

Я думаю, что в Disposing of Singleton нет ничего плохого. В сочетании с ленивым созданием это просто означает, что вы освобождаете ресурс, если он вам временно не нужен, а затем повторно получаете его по мере необходимости.

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