Должен ли я создать класс или добавить свойство

Question

В настоящее время я разрабатываю программное обеспечение для отслеживания и управления финансами отдельных лиц с использованием C#/WPF и шаблона MVVM. Это личный проект, который я делаю сам по себе, что я начал интересоваться приобретением большего количества знаний с этими технологиями и поставить в мое портфолио, поэтому без ограничений времени и денег/etc я стараюсь взять лучшее решения конструктивно.

В модельной части моего программного обеспечения в настоящее время у меня есть классы, такие как Expense и Income, которые наследуют открытый интерфейс ITransaction. У меня также есть классы, такие как BankAccount, CreditCard и Loan, которые наследуют открытый интерфейс IAccount. Расходы и доходы не имеют никакой разницы между ними, они имеют те же свойства, что и Name, Description и т. Д. То же самое касается BankAccount, CreditCard и Loan: все они имеют одинаковые свойства. Насколько мне известно, они не должны иметь методов, поскольку они не должны иметь никакой логики, реализованной непосредственно в них (кроме проверки свойств, которая может быть выполнена в самих свойствах).

Вопрос, который у меня есть на раннем этапе (я на самом деле только начинаю этот проект), должен ли я изменить этот дизайн, поскольку, пока они моделируют что-то конкретное из реальной жизни, у них нет никакой разницы между ними (Expense это всего лишь копия пасты Income и т. д.). Должен ли я менять свой дизайн, чтобы иметь, например, свойство TransactionType в классе Transaction, чтобы отличать доход от расхода, вместо того, чтобы тип класса имел это различие?

Каковы преимущества и недостатки каждого метода в долгосрочной перспективе?

Answer 1

В конце концов, я буду держать мой дизайн так, как это есть, который с и Expense и Income класса наследующегоИнтерфейс(то же самое относится к BankAccount, Loan и CreditCard с интерфейсом IAccount), поскольку, как отмечалось в комментариях, это было бы самым легким для рефакторинга, даже если наступил день, когда мне нужно различное поведение от этих классов. Это может быть так же просто, как и другая логика проверки свойств (что может иметь место, хотя они Expense и Income имеют только свойства и методы).

Кроме того, класс - это то, что должно быть смоделировано из объекта или концепции реальной жизни, которую использует ваше программное обеспечение. Я думаю, по этой причине Expense, Income и BankAccount, Loan и CreditCard должны быть классами, даже если на данный момент между ними нет разницы в логике, поскольку это понятия или «объекты», которые мое программное обеспечение должно моделировать.

Answer 2

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

public class Transaction 
{ 
    public string AccountNumber { get; set; } 

    public decimal Amount { get; set; } 

    public TransactionType TransType { get; set; } 
} 

public enum TransactionType 
{ 
    Income, 
    Expense 
} 

Если позже вы решите, что эти два понятия расходятся, и вам нужно отдельное функциональность для одного или другого, вы всегда можете создать отдельные классы, которые расширяют Transaction, которые следует надеяться предотвратить некоторые рефакторинга головные боли:

public class Credit : Transaction 
{ 
    public Credit() 
    { 
     TransType = TransactionType.Income; 
    } 

    public void SomeOtherMethodYouRealizedYouNeed() 
    { 
     // Do something 
    } 
} 

public class Expense : Transaction 
{ 
    public Expense() 
    { 
     TransType = TransactionType.Expense; 
    } 

    public int SomeNewProperty { get; set; } 
} 

Просто мои два цента ...