Как Вы осуществили бы рефакторинг это условное выражение для использования полиморфизма?

Вы будете на самом деле реализовывать что-то как Стратегическая модель. Запустите путем определения суперкласса, позволяет, называют это AbstractTableInfoCommand. Этот класс может быть абстрактным, но должен указать метод, названный runTableInfoCommand ().

Можно затем определить несколько sub классов что каждая реализация runTableInfoCommand () метод. Ваш класс, тот со свойством Number, будет затем иметь новое свойство типа AbstractTableInfoCommand (позволяет, называют это tableInfoCommand), который инстанцируют к одному из бетона sub классы AbstractTableInfoCommand.

Код затем будет:

public int Number
    {
        get
        {

            return this.tableInfoCommand.runTableInfoCommand();
        }
    }

Таким образом, можно создать NullTableInfoCommand и SomeOtherTableInfoCommand и т.д. Преимущество состоит в том, что, если у Вас есть некоторое новое условие для возврата tableinfocommand затем, Вы добавляете новый класс, а не редактируете этот код.

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

Я чувствую, что Ваш код прекрасно подходит. Читаемый. Простой. (И я надеюсь, что это работает). Если у Вас есть этот блок кода, повторяющийся n времена, необходимо удалить дублирование путем применения метода Извлечения.

Рефакторинг Вас указывает, предназначен для замены повторяющихся случаев переключателя.. не простой, если операторы как в Вашем примере. Замените Условное выражение Полиморфизмом. Помните 'самую простую вещь, которая работает'.. что означает минимальное количество классов и методов, требуемых сделать задание.

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

public class Thing
{
  public IValueFetcher ValueFetcher { get; set; }

  public int Number 
  { 
    get 
    {
      return this.ValueFetcher.GetValue<int>(/* parameters to identify the value to fetch */);
    }
  }
}

Это заботилось бы о большом количестве повторяющегося кода и уменьшило бы Вашу зависимость от источника значения к интерфейсу.

Я думаю в какой-то момент, что Вы, вероятно, будете иметь, если оператор как все еще необходимо решить, какую версию RunTableInfoCommand Вы хотите назвать.

Я принимаю internTableName и InternalTableNumber своего рода значение для того же самого. Почему бы не обернуть его в классе и передаче экземпляр того класса к this.RunTableInfoCommand как так:

public int Number
        {
            get
            {
                string returnValue;
                internalTableClass myinstance(parameters);
                return Convert.ToInt32(this.RunTableInfoCommand(myinstance, TableInfoEnum.TAB_INFO_NUM));
            }
        }

если Вы все еще хотите использовать полиморфизм затем, можно сделать так в том классе путем перегрузки, например, a giveInternalTableIdentifier это возвращает число или имя

код здесь мог затем быть похожим на это:

public int Number
        {
            get
            {
                string returnValue;
                internalTableClass myinstance(parameters);
                return Convert.ToInt32(this.RunTableInfoCommand(myinstance.giveInternalTableIdentifier, TableInfoEnum.TAB_INFO_NUM));
            }
        }

и код для internalTableClass будет тривиален (использование: internalAbstractTableClass и два класса, которые наследовались ему, одно давание имени и другого число),

Движение для рефакторинга, который включает полиморфизм, могло бы быть излишеством в этом случае (в зависимости от того, что другие преимущества Вы могли бы выйти из полиморфизма). В этом случае, добавляя простую перегрузку, которая инкапсулирует логику который RunTableInfoCommand() звонить могло бы быть в порядке.

С тех пор RunTableInfoCommand(), internalTableNumber, и internalTableName все, кажется, члены того же того же класса, хороший, легкий рефакторинг мог бы быть должен добавить перегрузку RunTableInfoCommand() это просто берет a TableInfoEnum оцените и делает логику выяснения который другой RunTableInfoCommand() перегрузку нужно назвать:

private string RunTableInfoCommand( TableInfoEnum infoEnum)
{
    if (this.internalTableNumber == null) {
        return this.RunTableInfoCommand( internalTableName, infoEnum);
    }

    return this.RunTableInfoCommand( internalTableNumber.Value, infoEnum);
}

Затем многочисленные сайты вызова, которые имеют то же if логика решения может быть свернута к:

returnValue = this.RunTableInfoCommand( TableInfoEnum.TAB_INFO_NUM);    
                                        // or whatever enum is appropriate

Я осуществил бы рефакторинг его таким образом:

table = this.internalTableNumber == null ? internalTableName : internalTableNumber.Value;
return Convert.ToInt32(this.RunTableInfoCommand(table, TableInfoEnum.TAB_INFO_NUM));

Любите тернарный оператор.

ОТРЕДАКТИРУЙТЕ 2, Как я действительно решил бы проблему.

Я сделал бы InternalTableNumber свойством, которое является лениво загруженный. Если бы это не доступно затем, я искал бы его через InternalTableName. Затем я всегда просто использовал бы свойство InternalTableNumber для своих методов.

 private int? internalTableNumber;
 private int InternalTableNumber
 {
     get
     {
         if (!internalTableNumber.HasValue)
         {
             internalTableNumber = GetValueFromTableName( internalTableName );
         }
         return internalTableNumber;
     }
     set
     {
         internalTableNumber = value;
     }
 }

 public int Number
 {
     get
     {
        string value = this.RunTableInfoCommand(InternalTableNumber,
                                                TableInfoEnum.TAB_INFO_NUM);
        return Convert.ToInt32( value );
     }
 }

РЕДАКТИРОВАНИЕ Используя полиморфизм...

Давайте предположим, что Ваш текущий класс называют Foo, затем я осуществил бы рефакторинг его в два класса, FooWithName и FooWithNumber. FooWithName был бы классом, который Вы будете использовать, когда у Вас будет имя таблицы, и FooWithNumber был бы классом для использования, когда у Вас есть число таблицы. Я затем записал бы каждый класс с методом Числа - на самом деле, я запишу интерфейс IFoo также, который каждый реализует так, чтобы они могли использоваться interchangably.

public interface IFoo
{
     int Number { get; }|

}

public class FooWithName : IFoo
{
     private string tableName;
     public FooWithName( string name )
     {
         this.tableName = name;
     }

     public int Number
     {
        get { return this.RunTableInfoCommand(this.tableName,
                                       TableInfoEnum.TAB_INFO_NUM);
     }

     ... rest of class, including RunTableInfoCommand(string,int);
}

public class FooWithNumber : IFoo
{
     private int tableNumber;
     public FooWithNumber( int number )
     {
         this.tableNumber = number;
     }

     public int Number
     {
        get { return this.RunTableInfoCommand(this.tableNumber,
                                       TableInfoEnum.TAB_INFO_NUM);
     }

     ... rest of class, including RunTableInfoCommand(int,int);
}

Вы использовали бы его в качестве так:

IFoo foo;

if (tableNumber.HasValue)
{
    foo = new FooWithNumber( tableNumber.Value );
}
else
{
    foo = new FooWithName( tableName );
}

int number = foo.Number;

Очевидно, если у Вас нет большого количества конструкций if-then-else в Вашем существующем классе, это решение на самом деле не улучшает его очень. Это решение создает IFoo использование полиморфизма и затем просто использует методы интерфейса, не заботясь о реализации. Это могло легко быть расширено для наследования общей реализации RunTableCommand (интервал) в абстрактном классе, который наследовал IFoo и является базовым классом для FooWithNum и FooWithName.

как я осуществил бы рефакторинг их конкретные если операторы для использования полиморфизма?

Хорошо... Я не был бы. Вам не нужен полиморфизм для устранения если операторы.

Обратите внимание, что, если операторы как не 'плохо' по сути, если операторы вызываются выбором представления где

(internalTableNumber == null) ==> 
    internalTableName else internalTableNumber.Value

Эта ассоциация подразумевает недостающий класс, т.е. имело бы больше смысла иметь класс InternalTable, который владел internalTableName и internalTablenumber, так как эти два значения сильно связаны правилом пустой проверки.

• Этот новый класс мог обеспечить свойство TableNumber, которое выполнило internalTableNumber == пустая проверка
• и RunTableInfoCommand мог взять экземпляр InternalTable в качестве параметра (но он не имеет к, посмотрите следующий объект).
• Но еще лучше, новый класс должен иметь фасад к методу RunTableInfoCommand (который, по-видимому, статичен), который выполнил целочисленное преобразование.

Принятие экземпляра InternalTable называют iTable, пересмотренный код беспокойства был бы затем похож:

public int Number
{
    get
    {
        return iTable.RunTableInfoCommand(TableInfoEnum.TAB_INFO_NUM);
    }
}

Это инкапсулировало бы пустую регистрацию класса InternalTable. Изменение исходной подписи RunTableInfoCommand является дополнительным.

Обратите внимание, что это "не заменяет, если операторы с полиморфизмом", но это действительно устраняет если операторы от класса потребления через инкапсуляцию.