C# Object Modeling decision

Question

I have a [ConfidentialInfo] object that is sent as input over the wire for further processing.

ConfidentialInfo
{
  confidentialInfo 1,
  confidentialInfo 2,
  confidentialInfo 3
}

I need to send back some derived values, after processing this input, as an object. Now, these values also bear close affinity to being part of the original input object.

ConfidentialInfo
{ 
 outputNotSoConfidentialInfo 1,
  outputNotSoConfidentialInfo 2
}

Should I model both the input and output together as one object - [ConfidentialInfo] or end up modeling 2 different objects ---- [ConfidentialInfoInput] and [ConfidentialInfoOutput]?

[Update and Elaboration] : My dilemma is:

If they are modeled as one which makes absolute sense btw, there is a need to differentiate it. There is no immediate grasp of what is input and output.

If they are modeled separate...differentiation is explicit but cohesiveness is gone. And there are equality checks and other comparisons that come into place to ensure that output was indeed derived from given input.

What is the sensible way to proceed?

Answer 1

I think you should make ConfidentialInfo as abstract class, so the [ConfidentialInfoInput] and [ConfidentialInfoOutput] classes will inherit from it.

Answer 2

Only you, the author of the code, know enough to make this call. To start you thinking down the right path, first consider the SOLID single responsibility principle by evaluating the impact of a small change in requirements to the hypothetical classes. If a small change requires updates in both classes then you have a tight coupling and should consider some form of common code; either as an Interface, or a common base class. If a small change would be likely only affect one of the two instances, then that is an argument for separation at some level.

Here are some more thought exercises to consider: the methods each class needs to support.

Case for 2 instances of a single class:

If both the inbound and outbound instances need to have the same methods, with the same code in them, then they should be instances of the same class with a flag like IsConfidential to trigger a (very, very) small change in behavior.

Case for 2 different classes:

If there is very little-to-no overlap in the methods required by each instance, then they should have two different base classes, but perhaps they can implement a common Interface so they have property type alignment.

Case for 2 classes from a shared base class

Both instances need to have the same methods, like a Validate() or Send(), but they need different implementations of those methods, then they should either have a base class which defines the commonalities and a base implementation, or just implement an interface which has those method signatures specified