В приведенном ниже классе только второй конструктор принимает объект ForumThread. В противном случае устанавливается значение null.
IncrementViewCount(), LockForumThread() и другие методы зависят от значения _ft, отличного от нуля.

Без извлечения нулевой проверки в новый частный метод, есть ли какой-нибудь более простой повторный факторинг, который я могу сделать, или лучший дизайн для защиты от использования неправильного конструктора с этими зависимыми методами?

private readonly IThread _forumLogic;
private readonly ForumThread _ft;

public ThreadLogic(IThread forumLogic)
    : this(forumLogic, null)
{
}

public ThreadLogic(IThread forumLogic, ForumThread ft)
{
    _forumLogic = forumLogic;
    _ft = ft;
}

public void Create(ForumThread ft)
{
    _forumLogic.SaveThread(ft);
}

public void IncrementViewCount()
{
    if (_ft == null)
        throw new NoNullAllowedException("_ft ForumThread is null; this must be set in the constructor");

    lock (_ft)
    {
        _ft.ViewCount = _ft.ViewCount + 1;
        _forumLogic.SaveThread(_ft);
    }
}

public void LockForumThread()
{
    if (_ft == null)
        throw new NoNullAllowedException("_ft ForumThread is null; this must be set in the constructor");

    _ft.ThreadLocked = true;
    _forumLogic.SaveThread(_ft);
}
0
asn1981 7 Апр 2010 в 19:07

2 ответа

Лучший ответ

Если вы реализуете свойство для ForumThread, вы можете выбросить исключение из get, если оно имеет значение null. Это может создать метод в базовом IL, но это не новый частный метод в вашем классе (плюс - что не так с новым методом?)

0
Leom Burke 7 Апр 2010 в 19:15
Причина, по которой мне не нужен новый частный метод, заключается в том, что вызов этого метода будет первой строкой в ​​любом последующем созданном общедоступном методе, который должен использовать объект набора конструкторов, не говоря уже о том, что разработчики не забывают вызывать частный метод при добавлении новый публичный метод.
 – 
asn1981
7 Апр 2010 в 19:19
Понятно. Если у вас есть свойство, вы можете просто вызвать для него свой метод, и он будет выброшен из получателя. Это должно дать вам правильное поведение. Вы всегда можете удалить конструктор, принимающий один параметр, и выдать ошибку, если в него передано значение null.
 – 
Leom Burke
7 Апр 2010 в 19:22
Конструктор single param требуется в некоторых случаях, например. Создавать(). Мне нравится идея просто проверить / добавить свойство Get, это имеет гораздо больший смысл.
 – 
asn1981
7 Апр 2010 в 19:24
Я сделал ваше предложение ответом. Это просто, но эффективно, иногда чрезмерное усложнение тоже нехорошо!
 – 
asn1981
7 Апр 2010 в 19:44

Почему бы не создать подкласс ThreadLogic и не предоставить дополнительный конструктор и зависимые методы только в подклассе? В качестве альтернативы, если у вас уже есть какая-то иерархия, вы можете использовать шаблон делегирования и декоратора для добавления новых функций. В обоих случаях вы можете проверить null в одном месте: конструктор

0
SergGr 7 Апр 2010 в 19:23