You wrote

The MyObj class has constructors for creating instances with either a TypeOneObj or a TypeTwoObj, but not both.

...

With the way that the class is constructed now, it gives the impression that there is a scenario under which you could have both baz and fuz data present, but that isn't the case.

I think this is missing the point, these two statements are actually contradictional.

Your current design does exactly the opposite: a user of the class who looks at the available constructors sees clearly that only a TypeOneObj or a TypeTwoObj can be passed, but not both. So users of the class have no reason to assume both types of objects are present at the same time.

If you have maintainers of the class in mind: those can be easily adressed by a comment in the code that only baz or fuz will be initialized, and unit tests which test each new functionality with objects of both kinds.

But the real issue is a different one: once an object x of type MyObj is constructed and passed around, it may not be obvious whether x was initialized with Type1Obj or Type2Obj. This may or may not be a problem:

• when MyObj only has methods which work for both types, and hence abstract the internal state category (Type1Obj or Type2Obj) away from the user, then there is no need to distinguish between MyObj objects of both types from the outside.

• when MyObj offers certain public methods which work only when initialized with a Type1Obj, and others which work only when initialized with a Type2Obj, then your proposed design with two derivations start to make sense. Otherwise, it would be overdesign.

Sometimes it is sufficient to implement a boolean property in MyObj which allows a user to check the type of former initialization at run time. That's particular an option when you need this check only once or twice in the code.

I think that's enough of an answer, since you left out any information on how MyObj will be used in your code and most of any other useful context, I could only guess around what kind of design will be most suitable for your case.

You wrote

The MyObj class has constructors for creating instances with either a TypeOneObj or a TypeTwoObj, but not both.

...

With the way that the class is constructed now, it gives the impression that there is a scenario under which you could have both baz and fuz data present, but that isn't the case.

I think this is missing the point, these two statements are actually contradictional.

Your current design does exactly the opposite: a user of the class who looks at the available constructors sees clearly that only a TypeOneObj or a TypeTwoObj can be passed, but not both. So users of the class have no reason to assume both types of objects are present at the same time.

If you have maintainers of the class in mind: those can be easily adressed by a comment in the code that only baz or fuz will be initialized. Unit tests which test each new functionality with objects of both kinds will make sure that comment won't get overlooked, without complicating things by extra subclasses.

But the real issue is a different one: once an object x of type MyObj is constructed and passed around, it may not be obvious whether x was initialized with Type1Obj or Type2Obj. This may or may not be a problem:

• when MyObj only has methods which work for both types, and hence abstract the internal state category (Type1Obj or Type2Obj) away from the user, then there is no need to distinguish between MyObj objects of both types from the outside.

• when MyObj offers certain public methods which work only when initialized with a Type1Obj, and others which work only when initialized with a Type2Obj, then your proposed design with two derivations start to make sense. Otherwise, it would be overdesign.

Sometimes it is sufficient to implement a boolean property in MyObj which allows a user to check the type of former initialization at run time. That's particular an option when you need this check only once or twice in the code.

Since you left out any information on how MyObj will be used in your code and most of any other useful context, I can only guess around what kind of design will be most suitable for your case, so decide for yourself.

You wrote

The MyObj class has constructors for creating instances with either a TypeOneObj or a TypeTwoObj, but not both.

...

With the way that the class is constructed now, it gives the impression that there is a scenario under which you could have both baz and fuz data present, but that isn't the case.

I think this is missing the point.

Your current design does exactly the opposite: a user of the class who looks at the available constructors sees clearly that only a TypeOneObj or a TypeTwoObj can be passed, but not both. So users of the class have no reason to assume both types of objects are initialized at the same time.

If you have maintainers of the class in mind: those can be easily adressed by a comment in the code that only baz or fuz will be initialized, and unit tests which test each new functionality with objects of both kinds.

But the real issue is a different one: once an object x of type MyObj is constructed and passed around, it may not be obvious whether x was initialized with Type1Obj or Type2Obj. This may or may not be a problem:

• when MyObj only has methods which work for both types, and hence abstract the internal state category (Type1Obj or Type2Obj) away from the user, then there is no need to distinguish between MyObj objects of both types from the outside.

• when MyObj offers certain public methods which work only when initialized with a Type1Obj, and others which work only when initialized with a Type2Obj, then your proposed design with two derivations start to make sense. Otherwise, it would be overdesign.

You wrote

The MyObj class has constructors for creating instances with either a TypeOneObj or a TypeTwoObj, but not both.

...

With the way that the class is constructed now, it gives the impression that there is a scenario under which you could have both baz and fuz data present, but that isn't the case.

I think this is missing the point, these two statements are actually contradictional.

Your current design does exactly the opposite: a user of the class who looks at the available constructors sees clearly that only a TypeOneObj or a TypeTwoObj can be passed, but not both. So users of the class have no reason to assume both types of objects are present at the same time.

If you have maintainers of the class in mind: those can be easily adressed by a comment in the code that only baz or fuz will be initialized, and unit tests which test each new functionality with objects of both kinds.

But the real issue is a different one: once an object x of type MyObj is constructed and passed around, it may not be obvious whether x was initialized with Type1Obj or Type2Obj. This may or may not be a problem:

• when MyObj only has methods which work for both types, and hence abstract the internal state category (Type1Obj or Type2Obj) away from the user, then there is no need to distinguish between MyObj objects of both types from the outside.

• when MyObj offers certain public methods which work only when initialized with a Type1Obj, and others which work only when initialized with a Type2Obj, then your proposed design with two derivations start to make sense. Otherwise, it would be overdesign.

Sometimes it is sufficient to implement a boolean property in MyObj which allows a user to check the type of former initialization at run time. That's particular an option when you need this check only once or twice in the code.

I think that's enough of an answer, since you left out any information on how MyObj will be used in your code and most of any other useful context, I could only guess around what kind of design will be most suitable for your case.