C#, ASP.net Веб-проект , есть таблица , по сути подобие баг-трекинга, в зависимости от состояния записи ее нужно отображать по разному. Но состояние не одно, а несколько независимых. Например есть состояния "на исполнении", "не назначено". А есть еще тип проекта "веб", "gui" и т.п. В зависимости от комбинаций этих состояний нужно по разному раскрашивать ( фон, шрифт ), активировать разные линки в какой-то колонке делать активной ссылку, в другой прятать совсем.

Сейчас это делается при помощи if-ов в методе RowBound читается очень плохо, логику работы восприять очень сложно.
Какой паттерн для этих случаев использовать ?

Здравствуйте, Аноним, Вы писали:

А>C#, ASP.net Веб-проект , есть таблица , по сути подобие баг-трекинга, в зависимости от состояния записи ее нужно отображать по разному. Но состояние не одно, а несколько независимых. Например есть состояния "на исполнении", "не назначено". А есть еще тип проекта "веб", "gui" и т.п. В зависимости от комбинаций этих состояний нужно по разному раскрашивать ( фон, шрифт ), активировать разные линки в какой-то колонке делать активной ссылку, в другой прятать совсем.

А>Сейчас это делается при помощи if-ов в методе RowBound читается очень плохо, логику работы восприять очень сложно.
А>Какой паттерн для этих случаев использовать ?

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

Здравствуйте, Аноним, Вы писали:

http://en.wikipedia.org/wiki/State_pattern

Здравствуйте, Аноним, Вы писали:

А>C#, ASP.net Веб-проект , есть таблица , по сути подобие баг-трекинга, в зависимости от состояния записи ее нужно отображать по разному. Но состояние не одно, а несколько независимых. Например есть состояния "на исполнении", "не назначено". А есть еще тип проекта "веб", "gui" и т.п. В зависимости от комбинаций этих состояний нужно по разному раскрашивать ( фон, шрифт ), активировать разные линки в какой-то колонке делать активной ссылку, в другой прятать совсем.

А>Сейчас это делается при помощи if-ов в методе RowBound читается очень плохо, логику работы восприять очень сложно.
А>Какой паттерн для этих случаев использовать ?

State, конечно.
А объекты брать из фабрики, чтобы понапрасну память не дергать.

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

А>>Какой паттерн для этих случаев использовать ?

O>State, конечно.
O>А объекты брать из фабрики, чтобы понапрасну память не дергать.

State — не к месту тут. Он нужен, когда у объекта меняется состояние в ходе жизни. Тут, как уже посоветовал gandjustas, больше подходит Статегия.

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

L>State — не к месту тут.

Я бы не был настолько категоричен. Неозвученные в исходном посте вводные могут неоднократно все изменить.

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

L>>State — не к месту тут.

ZS>Я бы не был настолько категоричен. Неозвученные в исходном посте вводные могут неоднократно все изменить.

Там достаточно озвучено, чтобы понять, что State тут непричем.

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

L>State — не к месту тут.
L>Там достаточно озвучено, чтобы понять, что State тут непричем.

Там слово "состояние" встречается четыре раза, а "стратегия" — ни разу.
Как по мне, так это верный признак того, что нужно использовать State.
Ну а если серъезно, то нужно намного больше вводных данных, чтобы сказать однозначно.

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

O>Там слово "состояние" встречается четыре раза, а "стратегия" — ни разу.
O>Как по мне, так это верный признак того, что нужно использовать State.

Нет, не нужно. State — это не когда слово "состояние" используется, а когда состояние объекта меняется во времени, это важно.

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

L>Нет, не нужно. State — это не когда слово "состояние" используется, а когда состояние объекта меняется во времени, это важно.
Ну возможно. Я бы вообще ни тот ни другой паттерн тут не использовал. Привык находить паттерны в дизайне, а не применять для.

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

L>State — это не когда слово "состояние" используется, а когда состояние объекта меняется во времени, это важно.

Всегда считал, что паттерны должны выражать решение в терминах задачи.
В общем, готов с Вами и поспорить, но не вижу особого смысла.

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

L>>State — это не когда слово "состояние" используется, а когда состояние объекта меняется во времени, это важно.

O>Всегда считал, что паттерны должны выражать решение в терминах задачи.

Отлично. Перименуем поле "Состояние" в "Статус", так сразу State Pattern исчезнет? Сильно.

O>В общем, готов с Вами и поспорить, но не вижу особого смысла.

Тут нет предмета для спора. Достачточно открыть описание этого паттерна.

Здравствуйте, <Аноним>, Вы писали:

А>Какой паттерн для этих случаев использовать ?
Эээ, как обычно, мой любимый: "Здравый смысл".


А>Сейчас это делается при помощи if-ов в методе RowBound читается очень плохо, логику работы восприять очень сложно.
Не вижу ничего плохого в if-ах, когда они сконцентрированы в одном месте и не мешают восприятию логики (тем более даже фабрика стратегий будет на иф-ах).



В данном же случе мне больше по душе сл. подход (но, боюсь, паттернами там и не пахнет):
(Непонятно зачем здесь стратегия, раз алгоритм рисования всегда один и тот же?)


1) Заводим структуру содержащую всю информацию о стиле:

public class PageStyle 
{
    Color BackgroundColor;
    Font Font;
    
    bool ActivateXYZLink;
    bool HideDFGLink;
}

2) Фабрика стилей:

public PageStyle GetStyleFor(PageState type)
{
    if (type == PageState.InWork)
        return getInWorkStyle();
    if (type == PageState.Assigned)
        return getAssignedStyle();
    if (type == PageState.InQA)
        return getInQAStyle();

    // ...
}

3) Использование:

{
    var style = Styles.GetStyleFor(page.State);
    
    //...
    if (style.ActivateXYZLink)
        //activate
    else
        //deactivate

    //...
}

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


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

СУВ, Aikin

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

А>>Сейчас это делается при помощи if-ов в методе RowBound читается очень плохо, логику работы восприять очень сложно.
A>Не вижу ничего плохого в if-ах, когда они сконцентрированы в одном месте и не мешают восприятию логики (тем более даже фабрика стратегий будет на иф-ах).
Избыточное количество ифов банально заменяется таблицей.

A>В общем, задачи нужно решать, а не искать какие бы паттерны заиспользовать.

Поймал себя на мысли что полностью прочитал пост ТС только после твоего сообщения.
Обычно в вопросе про паттерны ответ содержится в последнем предложении. Вот и читаю с конца, часто не доходя до середины. А ведь действительно во многих случаях паттерны и не нужны.

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

G>Обычно в вопросе про паттерны ответ содержится в последнем предложении. Вот и читаю с конца, часто не доходя до середины. А ведь действительно во многих случаях паттерны и не нужны.

Да они если и не нужны, то только чтобы в документации написать или класс назвать. А применять можно некоторые базовые принципы (они же паттерны )), как то: абстракцию, делегирование, разделение (объединение) поведения и данных, диспатчеризицию (данными или поведением)... А уж если их комбинация на выходе дает Визитера, то так и запишем. Я конечно утрирую...

Спор ниочем. Далеко не всегда можно взять и четко применить паттерн в чистом в виде к определенной проблеме. На мой взгляд здесь более четко прослеживается State, так как именно внутреннее состояние и меняется под действием каких-то внешних факторов.

class AbstractState {
abstract void paint();
}

class Incident {
AssignedState assignedState;
InProgressState inProgressState;
ClosedState closedState;
AbstractState currentState;

void paint() {
...
currentState.paint();
...
}
}

А вот для типа проекта (веб, гуи) наверное больше подойдет стратегия как раз, так как оно часто меняться не будет и скорее всего будет задаваться только один раз при создании.

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

V>А вот для типа проекта (веб, гуи) наверное больше подойдет стратегия как раз, так как оно часто меняться не будет и скорее всего будет задаваться только один раз при создании.

Тип проекта тут не вообще не при чем. А по поводу того, что состояние не меняется вы правы, но это-то как раз аргумент против использования State-а.

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

L>Тут нет предмета для спора. Достачточно открыть описание этого паттерна.

Действительно, тут и так все ясно.

Я имею ввиду не тип проекта, в котором автор пишет это приложение , а требования, которые он озвучил. У исследуемого объекта есть несколько параметров: статус и тип проекта. Статус меняется часто — используем State. Тип проекта (просто другое поле этого объекта) меняется редко, как правило выставляется только при создании объекта, — используем Strategy.
Получается своеобразный гибрид.

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

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

L>>State — это не когда слово "состояние" используется, а когда состояние объекта меняется во времени, это важно.

O>Всегда считал, что паттерны должны выражать решение в терминах задачи.

Вобще говоря это так. Но есть нюансы, которые все меняют.

Например — м стейт и стратегия это состояние