Доступный одиночный элемент в C#

Ruby sass устарела уже некоторое время, разработка движется в сторону реализации Dart , в то время как LibSass также является реальной реализацией, но может отставать от реализации Dart некоторые аспекты. LibSass имеет множество интеграций для разных языков, пожалуйста, обратитесь к документации по ссылке выше.

Обе эти реализации намного быстрее, чем Ruby sass, и не создают никаких дополнительных каталогов кеша.

12
задан ripper234 22 October 2008 в 13:48
поделиться

8 ответов

Mark Release как internal и используйте InternalsVisibleTo атрибут для воздействия его только блока поблочного тестирования. Можно или сделать это, или если Вы будете осторожны, то кто-то в Вашем собственном блоке назовет его, можно отметить его как private и доступ это с помощью отражения.

Используйте финализатор в своем одиночном элементе, который звонит Dispose метод на одноэлементном экземпляре.

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

12
ответ дан 2 December 2019 в 04:43
поделиться

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

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

Что Ваш производственный код собирается сделать?

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

14
ответ дан 2 December 2019 в 04:43
поделиться

Одиночные элементы не должны быть Доступными. Период. Если кто-то звонит, Располагают преждевременно, Ваше приложение завинчено, пока оно не перезапускает.

4
ответ дан 2 December 2019 в 04:43
поделиться
 public class Foo : IDisposable
  { [ThreadStatic] static Foo _instance = null;

    private Foo() {IsReleased = false;}

    public static Foo Instance
     { get
        { if (_instance == null) _instance = new Foo();
          return _instance;
        }
     }

    public void Release()
     { IsReleased = true;
       Foo._instance = null;
     }

    void IDisposable.Dispose() { Release(); }

    public bool IsReleased { get; private set;}

  }
2
ответ дан 2 December 2019 в 04:43
поделиться

Если класс реализует IDisposable (поскольку Вы подразумеваете, что он делает), затем просто называют x. Расположите ()

0
ответ дан 2 December 2019 в 04:43
поделиться

Вы могли использовать вложенный ленивый одиночный элемент (См. здесь) с некоторыми простыми модификациями:

public sealed class Singleton : IDisposable
{
    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            if (!Nested.released)
                return Nested.instance;
            else
                throw new ObjectDisposedException();
        }
    }

    public void Dispose()
    {
         disposed = true;
         // Do release stuff here
    }

    private bool disposed = false;

    class Nested
    {
        // Explicit static constructor to tell C# compiler
        // not to mark type as beforefieldinit
        static Nested()
        {
        }

        internal static readonly Singleton instance = new Singleton();
    }
}

Не забудьте бросать ObjectDisposedException во все общедоступные методы/свойства объекта, если он был расположен.

Вы должны также, предоставлять метод финализатора для объекта, в случае, если Располагают, не становится названным. Посмотрите, как правильно реализовать IDisposable здесь.

0
ответ дан 2 December 2019 в 04:43
поделиться

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

В Вашем случае вероятно, необходимо лучше использовать шаблон "фабрика" (краткий обзор/метод - какой бы ни является лучшим для случая), объединенный с одиночным элементом.

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

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

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

0
ответ дан 2 December 2019 в 04:43
поделиться

Еще один вариант изготовления одноразового синглтона - использовать атрибут SandCastle [Singleton] для вашего класса. , а затем Castle Framework заботится об утилизации всех одноразовых предметов Singleton

0
ответ дан 2 December 2019 в 04:43
поделиться
Другие вопросы по тегам:

Похожие вопросы: