CODEWITHSUNDEEP
c#architecture
nfplee
nfplee

Reputation: 7977

Parent/Child Architecture Issue

my application has the following structure:

public class Transaction
{
   public int TransactionID { get; set; }
   public TransactionTypes Type { get; set; } // Enum for the type of transaction
   public decimal Amount { get; set; }
   public virtual decimal GrandTotal { get; set; } // In this case this would simply be the Amount
}

public class MembershipTransaction : Transaction
{
   public decimal ExtraAmount { get; set; }
   public override decimal GrandTotal { get { return base.GrandTotal + ExtraAmount; } }
}

I was wondering whether the GrandTotal against the transaction should include the ExtraAmount automatically. The benefits of this is that if i get all the transactions the GrandTotal figure will be correct regardless of the type of transaction. With the above logic i currently have to switch over each transaction type and return the GrandTotal for the derived type.

I'd appreciate it if someone could clear this up for me. Thanks

Upvotes: 0

Views: 116

Answers (3)

Si Robinson
Si Robinson

Reputation: 96

Having Extra Amount as part of the inheriting class and overiding Grand Total will break Liskov's Principle of Substitution as far as I am aware. ExtraAmount and the calculation for GrandTotal should be incorporated in your base class.

Hope that helps.

Upvotes: 1

Adriaan Stander
Adriaan Stander

Reputation: 166376

I would recomend that you include it in the base, so that you can use an interface/abstract class.

Each individual transaction type should know how to calculate its own Extra amount (being zero, percentage of Amount, fixed bracketed amounts), so that the business logic resides in the class overriding the base/abstract class.

This will allow you to make use of the grand total without knowing what the actual transaction type is.

Upvotes: 2

Fredrik Mörk
Fredrik Mörk

Reputation: 158309

A Grand Total is a Grand Total, and as such it would make sense if it included the ExtraAmount. This also makes sense in the context that code may only require knowledge about the base class Transaction to obtain a correct GrandTotal value.

As a side note; what purpose does the TransactionTypes enum have? Is it not enough to examine the type of the transaction object itself?

Upvotes: 2

Related Questions