I am creating a class diagram for what I thought was a fairly simple problem. However, when I get to the bottom of the hierarchy, all of the classes only contain one field and it is the same one.

This to me looks very wrong, but this field does not belong in any of the parent classes. I was wondering if there are any suggested design patterns in a situation like this?

A simplified version of the class diagram can be found below.

Note, fields named differently cannot belong to any other class

                        |   NoteMapping    |
                        | String noteId    |
                        | String content   |
                        |                  |
                  |                                |
         +--------|--------+              +--------|--------+
         |     UserNote    |              |    AdminNote    |
         |-----------------|              |-----------------|
         | String userId   |              | String adminId  |
         |                 |              |                 |
         +--------+--------+              +--------+--------+
                  |                                |
                  |                                |
         +--------|--------+              +--------|--------+
         |  UserBookNote   |              |  AdminBookNote  |
         |-----------------|              |-----------------|
         | String bookId   |              | String bookId   |
         |                 |              |                 |
         +-----------------+              +-----------------+

ASCII tables drawn using http://www.asciiflow.com/


I have added some class and field names to the class diagram above.

The reason bookId cannot exist in any of the parent classes is because it is used to create a OneToOne relationship with another class - which is not something that we always want to do.

  • 4
    this field does not belong in any of the parent classes -- Why? Nov 30, 2012 at 16:26
  • 2
    If I said "Multipe Inheritance" would I be shot? :-)
    – jwernerny
    Nov 30, 2012 at 16:39
  • 2
    You are going to find that your structure is wrong somewhere. Perhaps you should be preferring composition over inheritance on one or both levels. Unfortunately, without accurate names, we're not going to be able to help you figure out where the problem is.
    – pdr
    Nov 30, 2012 at 16:39
  • I agree 100% to @pdr. Don't expect to get a meaningful answer without telling us what ObjectA, ObjectAA etc. really stand for.
    – Doc Brown
    Nov 30, 2012 at 16:43
  • 1
    Maybe the class diagram is wrong, but the fact that it's done in ASCII art has its merits. Nov 30, 2012 at 19:03

3 Answers 3


The scenario you described probably means that there is an element (the field you are worrying about) that actually cames from a different hierarchy. This seems to be the typical use-case for multiple inheritance, as jwernerny already said in a comment.

Think to this: all existing cars derive (inherit) from an abstract "car" of some type. You can draw a tree that links all of them (a family tree). In which point of the family tree would you put the GPS navigator that you can see inside every modern car?

Most likely, you would end with a field named "GPS navigator" in each bottom (most modern) class of your tree. This happens because the GPS navigator comes from a different world (electronics) and does not have anything to share with cars.

Is this your situation?

  • +1 Thanks for the answer. Yes, that is a pretty accurate description of the problem. The field is purely to create a relationship with another object. However, as I am using Java, multiple inheritance is not really an option. What options would you suggest this leaves me with? Dec 2, 2012 at 16:46
  • Most likley you will have to use interfaces. Have a look at this article for a description of intefaces and of abstract classes (another "tool" that you will probably have to use in your solution): javabeginner.com/learn-java/java-abstract-class-and-interface . Dec 2, 2012 at 21:03

I'd just put String five in ObjectAA or ObjectAB or even ObjectA, then just accept that it will be blank or null most of the time. I might not do this if I suspected ObjectAAA and ObjectABA were going to get enhanced in the future, or if it really made the logic much easier to follow. I guess the bottom line is, which way is easiest to understand?

There are really three ways a class stands apart from others.

It may have different data stashed in it, which is pretty much what we are discussing here.

Or it's methods might do different things--same name, but different code. If that applies here, then I wouldn't worry about duplicate fields. You should use different classes if they do different things even though they contain no new fields.

Or it just might mean something different to the programmer. This is usually a function of fields, methods, and future intent. If it makes more sense, go with it. (But if two classes are identical in fields and methods--or even close--you might want to ask yourself if the two different concepts behind them are really one and the same.)

  • 2
    Suggesting to move around attributes without knowing what ObjectA, ObjectAA etc. really stands for is just guessing around (and most probably guessing wrong).
    – Doc Brown
    Nov 30, 2012 at 16:39
  • 1
  • @pdr: great link :-)
    – Doc Brown
    Nov 30, 2012 at 16:45
  • @DocBrown: Undoubtedly. That's just where I'd start from if it was my problem. If you can figure out why you wouldn't do that, you're halfway to knowing what you should do. Nov 30, 2012 at 16:49

Sometimes code duplication is a good practical approach.

Did I really write that? Don't shot me now, listen first.

As stated several times: without a concrete case it's hard to tell, but sometimes it is easier to live with the consequences of a little duplication. When it comes to a special case, C++ developer shout: multiple inheritence, while Java enthusiasts hum Generics. I say KIS - keep it simple. Not too simple, i.e. not simpler as the problem itself, but neither more complex! IMO you gain more benefit of clear structures than of a generic system that may cover everything (at the costs of readability).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.