Перечисление vs Таблица поиска против Перечисления enum против шаблона State - PullRequest
Новая
       14

Перечисление vs Таблица поиска против Перечисления enum против шаблона State

6 голосов
/ 04 марта 2009

Программное обеспечение, которое я буду создавать, будет включать в себя переключение между приложениями. Определенные задачи могут быть выполнены в зависимости от статуса приложения. Я думал об использовании enum в качестве статуса 

public class Application
{
  public int Id {get;set;}
  public Status {get;set;}
}
public enum Status
{
  [Description("New")]New = 1, [Description("Closed")]Closed = 2
}

Но потом я подумал, что, может быть, хорошо использовать таблицу поиска в базе данных, так как статус часто обновляется / переупорядочивается 

table status (id int pk, desc string, sort_order int)
table application (id int pk, status_id int fk)

В моем случае мне нужно сделать что-то вроде 

if (application.Status == Status.New)
{ //do something }
else if (application.Status == Status.Closed)
{ //do other things }

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

Должен ли я использовать отражение для динамического создания перечисления на основе значений из справочной таблицы? Или я должен использовать шаблон состояния? Проблема, с которой я сталкиваюсь при перечислении перечислений, - это влияние на производительность. А шаблон состояний может создавать много избыточного кода.

Что вы думаете? Заранее спасибо!

Ответы [ 3 ]

7 голосов
/ 04 марта 2009

Вы не должны разбрасывать свой код этой проверкой везде 

if (application.Status == Status.New)
{ //do something }
else if (application.Status == Status.Closed)
{ //do other things }

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

Что касается изменения статуса, то это никак не связано с шаблоном состояния. Таким образом, вы можете использовать любой подход, элегантный.

3 голосов
/ 04 марта 2009

Я бы создал класс Status, содержащий различия, и вызвал бы их. Итак (в Python): 

class StatusZero(object):
    def call_me(self, app):
       print 'Hello, from ' + app.name
       return db.prepare_specific_status_zero_request()


class StatusOne(object):
    def call_me(self, app):
        print 'Hi, from ' + app.name
        return db.prepare_specific_status_one_request()

states = { 'status_zero' : StatusZero(), 'status_one' : StatusOne() }

class Application(object):
    name = 'My App'
    status = states['status_zero']

    def change_state(self, state):
        status = state

    def call_me(self):
        state_key = self.status.call_me(self)
        self.change_state(states[state_key])

Быстро, легко сохранять функциональность разделенной на части, и с разумной схемой наследования между состояниями вы можете совместно использовать функции, которые не отличаются.

0 голосов
/ 04 марта 2009

Насколько я понимаю, шаблон состояния достаточно хорош только для пользовательского интерфейса или только в памяти, где в моей ситуации при извлечении данных из таблицы приложения все еще требуется оператор if, чтобы определить, к какому объекту приводиться. 1001 * 

public AbstractApplication convert_db_application_to_object(obj db_application)
{
   AbstractApplication app;
   if (db_application.Status == (int)Status.New)
      app = application_factory.create(application_state_new);
   else if(db_application.Status == (int)Status.Closed)
      app = application_factory.create(application_state_closed);

   return app;
}

я не вижу в этом элегантного решения так как мне все еще нужна таблица enum или lookup для сохранения статуса приложения в базе данных

...