Question

I currently have a message system which writes to two tables, sent and received, which largely have the same schema.

I wrote a class called Message which populates the user inputted data before instantiating the two child classes which use a common method in Messageto set the rest of the properties and writing each to the database. The only significant difference is one field which is represented in the child class with its corresponding variable. All of the other properties are part of Message.

The thing is, Message has no purpose other than to provide common methods and properties for the objects created and facilitate access to the database class it’s a descendant of.

Is this considered bad practice? Is the Message class monolithic or should I push it further and incorporate the child classes for the sake of one field? Would a better approach be to separate the classes entirely and have one for sent and one for received tables?

Answer 1

It is not bad design. You basically created an abstract class. Such classes are not intended to be instantiated but contain code that is common in several other classes.

You followed a principle: DRY – Don’t repeat yourself.

Of course, if the difference is really really small, you probably make your design easier by putting everything in one class.