How to use same properties for separate API requests-CodePudding

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.