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

S>Чугуниевый прототип:

Нда, суровая ирония жизни: в итоге победил допиленный чугуниевый вариант с lock (changeStateLockKey) в каждом setter'е. Станет проблемой — перейдём к какому-нить из предложенных вариантов, благо теперь их есть

Огромное спасибо всем отметившимся!

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

S>Нда, суровая ирония жизни: в итоге победил допиленный чугуниевый вариант с lock (changeStateLockKey) в каждом setter'е. Станет проблемой — перейдём к какому-нить из предложенных вариантов, благо теперь их есть

Упс, забыл:

    protected void SafeSetValue<T>(ref T value, T newValue)
    {
      lock (changeStateLockKey)
      {
        ValidateNotBusy();
        value = newValue;
      }
    }

    protected void SafeSetValue<T>(ref T value, Func<T> newValueCallback)
    {
      lock (changeStateLockKey)
      {
        ValidateNotBusy();
        value = newValueCallback();
      }
    }

S>Огромное спасибо всем отметившимся!

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

S>ТС — это я И да, идея с паттерном состояния мне пока что нравится больше всего. Поскольку у базового класса туча наследников, может проще окажется _сначала_ переизобрести dependency properties, а _затем_ — реализовать вариант hardcase. В результате получится как раз Freezable из WPF

Еще вариант: сгруппировать все свойства в отдельном иммутбельном классе настроек, а SomeTask сделать одно свойство Settings в котором проверять ValidateNotBusy().
Обходимся средствами C#, и проще некуда .

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

A>Еще вариант: сгруппировать все свойства в отдельном иммутбельном классе настроек, а SomeTask сделать одно свойство Settings в котором проверять ValidateNotBusy().
A>Обходимся средствами C#, и проще некуда .

Ваше (и hardcase) решение красивое, но пока отложено до первых граблей и уже решено чугуневой заглушкой:

  protected void SafeSetValue<T>(ref T value, T newValue)
    {
      lock (changeStateLockKey)
      {
        ValidateNotBusy();
        value = newValue;
      }
    }

    protected void SafeSetValue<T>(ref T value, Func<T> newValueCallback)
    {
      lock (changeStateLockKey)
      {
        ValidateNotBusy();
        value = newValueCallback();
      }
    }

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

S>Как бы сделали вы?

dynamic proxy generator и в интерцепторе бросать исключение.

Проперти даже реализовывать не надо, все само будет.

Всякие Moq это используют. Можно даже в рантайме сконструировать логику интерцептора.

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

S>>Как бы сделали вы?

I>dynamic proxy generator и в интерцепторе бросать исключение.

Это даже не из пушки по воробьям, а ядрёной бомбой по таракану

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

S>Класс SomeTask может быть в двух состояниях:

S>- простаивает (можно изменять любые свойства, косяки с многопоточными обновлениями — проблемы вызывающего кода)
S>- работает (любые попытки изменить свойства/повторно запустить задачу, даже из другого потока — InvalidOperationException).

S>Чугуниевый прототип: ...

Чугуниевый прототип это:

public class SomeTask
{
    public void Run(SomeTaskOptions options)
    {
       _options = options.Copy();
    }
}

Task и набор параметров это две разных сущности, смешивать их вместе совсем не обязательно.

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

TK>Task и набор параметров это две разных сущности, смешивать их вместе совсем не обязательно.
Уже предлагалось (например, hardcase). Пока сделали проще (см выше

Автор: Sinix
Дата: 19.11.10

).

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

TK>>Task и набор параметров это две разных сущности, смешивать их вместе совсем не обязательно.
S>Уже предлагалось (например, hardcase). Пока сделали проще (см выше

Автор: Sinix
Дата: 19.11.10

).

Это хорошо пока, свойство у вас одно (хотя, зачем для такого случая вообще что-либо изобретать?). Если свойств становится два и более возникает вопрос, что будет если половина свойств поменялась а вторая половина не успела?

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

TK>Это хорошо пока, свойство у вас одно (хотя, зачем для такого случая вообще что-либо изобретать?). Если свойств становится два и более возникает вопрос, что будет если половина свойств поменялась а вторая половина не успела?

По ветке я расписывал основные юз-кейзы. Для нашей задачи проблема некритична: если кто-то попытается изменить значения в момент запуска задачи — это 100% баг и софт должен тут же умереть в страшных муках.

Но да, с общей точки зрения state pattern куда чище и красивее.

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

S>>>Как бы сделали вы?

I>>dynamic proxy generator и в интерцепторе бросать исключение.

S>Это даже не из пушки по воробьям, а ядрёной бомбой по таракану

Ради одного Freezable ты сам показал хороший код которого вполне достаточно.

Если Freezable будет больше — то есть готовые решения, одно из них я тебе и показал.