Правильный дизайн? Статические методы в статическом классе?

Question

У меня есть класс прямого депозита, который выглядит ниже.

public class DirectDeposit 
{ 
    private string ClientID = ""; 
    private string WorkerID = ""; 
    private string BankRoutingNumber = ""; 
    private string BankAccountNumber = ""; 
    private string BankAccountType = ""; 

    public DirectDeposit(string clientid, int workerID) 
    { 
     ClientID = clientid; 
     WorkerID = workerID.ToString(); 
     BankRoutingNumber = Utility.GetRoutingNumber(); 
     BankAccountNumber = Utility.GetAccountNumber(); 
     BankAccountType = Utility.GetAccountType(); 
    } 

    public override string ToString() 
    { 
     StringBuilder result = new StringBuilder(); 
     result.Append(ClientID + ","); 
     result.Append(WorkerID + ","); 
     result.Append(BankRoutingNumber + ","); 
     result.Append(BankAccountNumber + ","); 
     result.Append(BankAccountType + ","); 
     return result.ToString(); 
    } 
} 

}

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

public static class Utility 
{ 
    private static Random seed = new Random(); 

    public static string GetAccountNumber() 
    { 
     // gets a value between 0 and 999999999 
     int bankAcct = seed.Next(0, 1000000000); 
     return bankAcct.ToString(); 
    } 
    public static string GetAccountType() 
    { 
     List<string> AcctType = new List<string>() { "C", "S"}; 

     //seed.Next returns a value >= 0 and < Count 
     int index = seed.Next(0, AcctType.Count()); 
     return AcctType.ElementAt(index); 
    } 
} 

мне не совсем нравится этот подход, и предпочел бы эти быть частные методы внутри класса DirectDeposit. Это правильно?

Answer 1

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

Программирование с проверкой в ​​уме - это отличная помощь для написания лучшего кода, так как навязывает много хороших практик.

Я бы сделал эти статические методы, методы экземпляров и создал интерфейс IUtility, который вводится в конструктор DirectDeposit. Если вы посмотрите на свой код, возможно, вы не используете стратегию DI, но я настоятельно рекомендую вам начать его подготовку.

Вы можете взглянуть на SOLID принципы архитектуры для лучшей мотивации работы за этим (и другими) хорошей практикой.

Answer 2

Мне не совсем нравится этот подход и предпочел бы, чтобы это были частные методы внутри класса DirectDeposit. Это правильно?

Это правильно, если

• Методы используется только DirectDeposit класса
• Они являются частью нормальной функции класса (не для тестирования, отладки и т.д.)

Поскольку создание случайного номера счета и введите каждый раз, когда вы создаете DirectDeposit экземпляр кажется очень странным (как вы представляете существующий экземпляр депозита?) Трудно сказать, что «правильно» в вашем случае.

Answer 3

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

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

Также предложенная Клаудио Реди хорошая идея для тестирования, поэтому назовите ее IRandomAccountInfoGenerator (или что-то, что вам больше нравится).