Неизменный класс, подходящий, когда экземпляры используются в инструменте «что, если»? - PullRequest
Новая
       22

Неизменный класс, подходящий, когда экземпляры используются в инструменте «что, если»?

3 голосов
/ 17 марта 2011

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

Вкл.с другой стороны, будет GUI, позволяющий пользователю делать «что-если», в котором он может изменять параметры, чтобы увидеть, как он меняет значения модели.Поэтому я мог бы сделать модель изменчивой, чтобы сделать это проще, или создавать новые копии каждый раз, когда изменяется параметр.Последнее кажется неудобным, особенно если есть, например, 5 параметров, которые можно пометить по отдельности ... Возможно, мне придется реализовать метод SetX () для каждого параметра, который возвращает копию, верно?

Я обдумываю это, или здесь есть подходящая схема?(Это код C #, хотя я думаю, что он не зависит от языка)

Ответы [ 3 ]

3 голосов
/ 17 марта 2011

Тщательно продумайте, как объект будет фактически использоваться для вашего умозрительного анализа.Для простых одноразовых сценариев «давайте изменим поле, попробуем что-то и изменим - вернем», конечно, просто сделайте его изменчивым.Но предположим, что вы хотите вытащить большие пушки;тогда становится гораздо приятнее иметь неизменную модель. 

Data d = whatever;
// What if we mutate X and Y? Which one maximizes the value of Foo(d) ?
var query = from x in Range(0, 100)
            from y in Range(0, 100)
            let mutated = data.MutateX(x).MutateY(y)
            orderby Foo(mutated)
            select mutated;

var max = query.First();

И так далее.С неизменяемым шаблоном становится намного проще писать умозрительные запросы, становится намного проще распараллеливать эти запросы между несколькими ядрами и т. Д.

1 голос
/ 17 марта 2011

Последний кажется неловким

Ну, это твой ответ. Цель API-дизайна - сделать код максимально простым. Если определенный шаблон делает его более трудным или неудобным, чем альтернатива, альтернатива, вероятно, является правильной.

0 голосов
/ 17 марта 2011

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

Вы также можете разделить ваши классы на класс Data и класс Strategy, второй, который содержит изменяемые параметры и использует что-то вроде шаблона Strategy.рассчитать результаты.

...