Maintaining encapsulation seems to promote redundant classes
What I see here is a great scenario for composition!

What you say is that you're annoyed because CreateManualShipmentRequest already has the shipment informations. Alright so, why doesn't CreateManualShipmentRequest contains ShipmentRequestInfo instead of repeating all the information?

public class ShipmentRequestInfo
{
    public Address Sender { get; set; }
    public Address Recipient { get; set; }
    public PackageSizeAndWeight Package { get; set; }
    public Payor Payor { get; set; }

    public List&lt;string&gt; SpecialServices { get; set; }
    public decimal InsuredValue { get; set; }
    public string ServiceType { get; set; }
}

public class CreateManualShipmentRequest
{
    public ShipmentRequestInfo ShipmentRequestInfo { get; set; }

    public string ServiceProvider { get; set; }

    public string LabelImageFormat { get; set; }
    public bool TestMode { get; set; }
}


You're right that having redundant code is a code smell, but creating another class to keep encapsulation is most of the time a pretty good thing to do.

I wanted to address the comment stating that you could use interfaces. I feel like it's not a bad solution, but I don't think it's the right one.

Implementing an interface is kind of a "is a" relationship.

But, could you say : "CreateManualShipmentRequest is a ShipmentRequestInfo? I don't think so. Though, saying "CreateManualShipmentRequest contains ShipmentRequestInfo" seems pretty logical to me!

Sure, readability and serialization are good points. For the serialization, well.. APIs are good, you'll have to write a little bit more code to deal with that. Readability itself isn't that affected. But are those points valuable than :


Not having redundant code
Passing the wrong object to a method
Implementing an interface that is misleading


? I feel like you should use composition.