BackgroundHere's the actual problem I'm working on: I want a way to represent cards in the card game Magic: The Gathering.  Most cards in the game are normal-looking cards, but some of them are divided into two parts, each with its own name.  Each half of these two-part cards is treated as a card itself.  So for clarity, I'll use Card only to refer to something that's either a regular card, or half of a two-part card (in other words, something with only one name).So we have a base type, Card.  The purpose of these objects is really just to hold properties of the card.  They don't really do anything by themselves.interface Card {    String name();    String text();    // etc}There are two subclasses of Card, which I'm calling PartialCard (half of a two-part card) and WholeCard (a regular card).  PartialCard has two additional methods: PartialCard otherPart() and boolean isFirstPart().RepresentativesIf I have a deck, it should be composed of WholeCards, not Cards, as a Card could be a PartialCard, and that wouldn't make sense.  So I want an object that represents a physical card, that is, something that can represent one WholeCard, or two PartialCards. I'm tentatively calling this type Representative, and Card would have the method getRepresentative().  A Representative would provide almost no direct information on the card(s) it represents, it would only point to it/them.  Now, my brilliant/crazy/dumb idea (you decide) is that WholeCard inherits from both Card and Representative.  After all, they are cards that represent themselves!  WholeCards could implement getRepresentative as return this;.As for PartialCards, they don't represent themselves, but they have an external Representative that is not a Card, but provides methods for accessing the two PartialCards.I think this type hierarchy makes sense, but it's complicated.  If we think of Cards as conceptual cards and Representatives as physical cards, well, most cards are both!  I think you could make an argument that physical cards do in fact contain conceptual cards, and that they're not the same thing, but I would argue that they are.Necessity of Type-castingBecause PartialCards and WholeCards are both Cards, and there's usually no good reason to separate them out, I'd normally just be working with Collection<Card>.  So sometimes I'd need to cast PartialCards in order to access their additional methods.  Right now, I'm using the system described here because I really don't like explicit casts.  And like Card, Representative would need be cast to either a WholeCard or Composite, to access the actual Cards they represent.So just for summary:Base type RepresentativeBase type CardType WholeCard extends Card, Representative (no access needed, it represents itself)Type PartialCard extends Card (gives access to other part)Type Composite extends Representative (gives access to both parts)Is this insane?  I think it actually makes a lot of sense, but I'm honestly not sure.
How to make a datatype for something that represents either itself or two other things
java;object oriented design;hierarchy
It seems to me that you should have a class likeclass PhysicalCard {    List<LogicalCard> getLogicalCards();}Code that's concerned with the physical card can deal with the physical card class, and code that's concerned with the logical card can deal with that.I think you could make an argument that physical cards do in fact  contain conceptual cards, and that they're not the same thing, but I  would argue that they are.It doesn't matter whether or not you think the the physical and logic card are the same thing. Don't assume that just because they are the same physical object, they should be the same object in your code. What matters is whether adopting that model makes the coder easier to read and write. The fact is, adopting a simpler model where every physical card is treated as a collection of logical card consistently, 100% of time, will result in simpler code.