Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

ClassA{
 this.name
 this.weight
 this.height
 this.width

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

or

abstract ClassA{
 this.name
 this.weight
 this.height
 this.width
}

ClassB extends ClassA{
 this.name = '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
add comment

3 Answers

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
add comment

with your second example in most languages will create new fields in ClassB that are different from those in ClassA (objB.name 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
add comment

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
add comment

Your Answer

 
discard

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.