[potatosareok]

For some reason seeing your code really bothers me. Is it normal to ever use private variables in inheritance like that?

Say you had toString() in Article class that returned ("%s%" author, title).

Now if you create a MutableArticle on it, ma.toString() will return null unless you override toString on it as well (since Articles variables are private and not inherited).

I don't code much so I don't know is it normal to see code like that?

Also less relevant but Articles constructor should probably be public?

[organsnyder]

I agree that this design is sub-optimal. However, if a.toString() called the getters instead of using the instance variables directly, you wouldn't have problems.

The Article class is unusable as provided due to the private constructor (in fact, the MutableArticle class wouldn't even compile), but private constructors can be useful. I often use private constructors and instead provide public static methods that call the constructors. This practice is often derided, and goes into Java's perception as a verbose, arcane language, but it allows for improving an API without breaking clients built to previous versions, as well as making an API more clear (since we can give the static methods more descriptive names).

[potatosareok]

Thanks for taking time to reply. Didn't think about having toString use the getters instead of accessing the instances directly. I guess in some way that's the more proper way of doing it in the context of OOP.

I'm familiar with Java private constructors and builders/factory methods though, that was more of a minor nitpick, but again thanks for explaining on that.