Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What is better practice: force user to extend abstract class or make class with configuration? Eg. pseudocode:


 constr(config){ =
  this.weight = weight
  this.height = height
  this.width = width


abstract ClassA{

ClassB extends ClassA{ = 'Item'
 this.weight = 12
 this.height = 11
 this.width = 14

Until now i was using configuration because most libraries use this method, but whats wrong with second method? I recently found that method with extending is producing clearer code but maybe I am missing something?

share|improve this question
up vote 3 down vote accepted

Favor composition over inheritence comes into play here, though I'd favor neither if it's possible. Let the class worry about representing itself, construct it with sane defaults and let its consumer worry about how to populate it.

Beyond that, the general arguments for composition over inheritence apply.

share|improve this answer
This is exactly what I was looking for but couldn't figure out right google query ;) – Krzysiek Grzembski Aug 30 '13 at 14:08

with your second example in most languages will create new fields in ClassB that are different from those in ClassA ( will be different from ((ClassA)objB).name)

also you shouldn't force your user to inherit from classes if you can avoid it. This is largely because users can make mistakes and forget to initialize a field which leaves the object in a illegal state, or forget to update the implementation when a field gets added/removed

tl;dr: there is less chance of errors when all implementation details of a component are in a single place

share|improve this answer

When you're just specifying a bunch of simplistic settings (ie, strings, numbers, booleans) inheritance doesn't seem to be the right way to me; multiple instances would be pointless, and as ratcher said, properties defined wouldn't bind to the super-type's. For very low number of options, I'd say constructor arguments like your first example. For higher numbers, perhaps an XML configuration, or even a seperate object type (XYZLibraryConfig).

Not that inheritance for user configuration doesn't have its purposes, if the user is meant to fill in some amount of logic. In response to ratchet's worry of improper extension, I might lean more towards Interfaces, or Abstract classes that require all blanks to be filled in by the user; such that the only way to screw it up is if the customer themselves throws an exception or returns null in the methods they're responsible for.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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