Когда использовать enum, class или tags? - PullRequest
Новая
       20

Когда использовать enum, class или tags?

3 голосов
/ 12 сентября 2011

Представьте, что у вас есть страница определенного типа (например, обычная страница, страница учетной записи и т. Д.). Страница представлена ​​объектом Page.

Мой вопрос: как бы вы назначили тип страницы странице?

Я вижу эти варианты:

  1. с использованием перечисления PageType, установленного в объекте Page.
  2. с использованием класса PageType и назначением его экземпляров в объекте Page.
  3. с помощью тегов страницы, которые представляют собой простые строки, связанные с объектом Page.

Вариант 1 - только кодовый подход, поэтому добавление новых типов страниц означает изменение (основного) кода. Вариант 2 является более гибким, но он требует дополнительных затрат для поддержки этих типов страниц. Вариант 3 очень гибок, потому что не требует обслуживания и может быть распространен на другие механизмы, кроме типа страницы. Но вы можете легко сломать вещи, потому что нет никаких ограничений.

Какие могут быть другие объективные причины для выбора одного над другим?

Ответы [ 3 ]

2 голосов
/ 12 сентября 2011

А как насчет варианта 4?

Создание (абстрактного) базового класса с базовым поведением страницы и подкласса для каждой конкретной страницы. Это лучший дизайн, если вы ожидаете различий во многих разных местах. Это предотвращает необходимость написания switch операторов для оценки перечисления в десятках мест.

Избегайте использования «волшебных» строк, поэтому определенно предпочтите использовать подход 1 или 2, а не 3. На основании ваших требований, используя , шаблон стратегии для подключения различных типов поведения также может быть приемлемым вариантом. Это дает еще большую гибкость, но инициализация вашего класса станет немного более громоздкой. Конечно, это поведение снова может быть включено в метод класса / фабрики, выполняющий эту работу за вас.

2 голосов
/ 12 сентября 2011

Отсутствует подробная информация о дизайне системы и требованиях к страницам, количестве поддерживаемых типов страниц и разнице между самими страницами, поэтому трудно принять такое решение. В таком случае я бы порекомендовал сохранить его простым и использовать Enum .

  • Если у страниц есть своя специфическая бизнес-логика, вы можете придерживаться класса для каждого типа страницы, но делайте это осторожно только тогда, когда есть действительно специфичная для страницы логика.
  • Подумайте о функции UserControl / CustomControl (при условии, что вы используете ASP.NET), чтобы вы могли разделить страницу по набору элементов управления, отвечающих за функциональность страницы, поэтому таким образом вы сохраните Single Принцип ответственности и построение менее связанной системы.
  • Некоторая логика должна быть extracted из самих сущностей Page во внешние помощники / фабрики / репозитории, а затем внедряться в класс Page.

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

0 голосов
/ 13 сентября 2011

Ничего из вышеперечисленного.

Очевидный вопрос: почему вы хотите определить только тип страницы?Сама идентификация не полезна.Скорее всего, вы захотите сделать что-то еще со страницей.

Я бы создал интерфейсы для всех типов страниц, например IAccountingPage, а затем создал бы какое-то хранилище.Если вам необходимо предварительно обработать страницу до ее отображения, создайте интерфейс фильтра, например IPagePreFilter<T> where T : IPage, а затем внедрите его следующим образом: 

public class DiscountFilter : IPagePreFilter<ISalesPage>
{
    public void Process(ISalesPage page)
    {
        if (page.Product.Id == 1234)
            page.AddParagraph("Product is at amazing 50% off");
    }
}

Резюме: не пытайтесь идентифицировать страницы, чтобы иметь логику, подобную if (page.PageType == PageEnum.Accounting) bla blaпотому что это нарушает принцип замещения Лискова.Сделайте более надежное решение, подобное предложенному мной.

...