I have following two API methods:
[HttpPost]
public ActionResult<TransactionReadDto> TransactionGroup(TransactionGroup transactionGroup)
{
// some code goes here
}
[HttpPost]
public ActionResult<TransactionReadDto> TransactionHistory(TransactionHistory transactionHistory)
{
// some code goes here
}
And the above code TransactionGroup
and TransactionHistory
classes as follows:
public class TransactionGroup
{
public string Name { get; set; }
public string Publisher { get; set; }
public string Cost { get; set; }
}
public class TransactionHistory
{
public string Name { get; set; }
public string Publisher { get; set; }
public string StartDate { get; set; }
public string EndDate { get; set; }
}
You can see these two classes have same properties for Name
and Publisher
(it has more same properties than these two, this only for an example). My problem: is there any best way to handle this without using same properties in API request classes? Can I use inheritance?
If yes what is the way to do this? I mean can I put same properties into some parent class and inherit let TransactionGroup
and TransactionHistory
classes inherit from that base class? Is this a good approach?
CodePudding user response:
Generally, don't do it.
You would think that you actually remove redundant code by implementing inheritance or composition here. But the cost of reducing the amount of code is that you permanently couple the two API requests. There can be a future in which you want to change one of the API methods but not the other. This will be much harder if you have coupled these two (or even more of them).
Also, you do not really gain any readability by sharing the code. Instead, it would be even harder to read, because not all properties of TransactionHistory
will be found in its class.
If you find that there is really far too much code duplication, you would prefer composition like this:
public class TransactionHistory
{
public CommonTransactionData common { get; set; }
public string StartDate { get; set; }
public string EndDate { get; set; }
}
In this special case, you could also consider it to be clean using inheritance, but generally we follow the composition over inheritance principle.
edit: missed a property name
CodePudding user response:
What relation to TransactionGroup
and TransactionHistory
have? Is the one a subtype of the other (like for instance Vehicle -> Car
) or do they just have equally named properties. A Country
and a Person
both have a Name
, but that doesn't mean you should let a Person
inherit from a Country
or vice versa.
Especially, if I look at your classes, they both have exclusive properties (ie Cost
only exists in the TransactionGroup
and the StartDate
only in TransactionHistory
). But if you let one inherit from the other, it means the other will have all properties as well. Does it make sense for a Group
to have a StartDate
or does it make sense for a History
to have a Cost
? If not, inheritance is not the proper way.