What is the proper OOP way to configure class (dis)inheritance?

Question

I cannot seem to google this one correctly... I have a class (Widget) that represents a database table from the Data Layer.

The table holds 3 different types of records, where one uses only 5 columns, another uses 10 columns etc. Each record has a different set of validation and business rules that I want to control with Business Layer abstraction.

Is the proper thing to create 3 concrete classes and map the properties to the single database table class? I feel like I'm missing an opportunity to use an interface or inheritance?

If I want something like below wouldn't my Widget classes inherit from the database table class that holds all widgets? And if it did, then how would I "hide" or disinherit the properties betwen the specific widget types?

List<SmallWidget> sw = BusinessLayer.GetWidgets<SmallWidget>();
List<MediumWidget> mw = BusinessLayer.GetWidgets<MediumWidget>();
List<LargeWidget> lw = BusinessLayer.GetWidgets<LargeWidget>(); 

Thanks for the advice.

Answer 1

Inheritance is overrated!

If you can think of no reason to use inheritance (ie. there is no shared code) then don't use it.

It will just couple the classes together which will just cause pain in the long run.

You could make the table class a member of each of the widget classes. Then each widget could expose just the fields that is necessary.

You then get an added advantage that if you need to change one of the widgets to use a different table, you will only need to change a small area of code in one of the widgets.

See Prefer composition to inheritance.

Answer 2

If the business rules don't overlap, just ignore the fact that they are in the same table (maybe use views) and create three classes. If there are common rules, create a base class for those and inherit from it. The base class will have all the columns, but only expose the common ones. Expose the other columns in the appropriate descendent.

Answer 3

Keep your business objects as close to the actual business entities as possible - create three separate classes for the three types of widgets - SmallWidget, MediumWidget and LargeWidget. Let there be a single data class - WidgetData that maps to the table. You can then implement the three widget classes using any ONE of the following strategies:

• Add the relevant fields to each of the three classes. Also add a constructor that takes an object of type WidgetData. The constructor can initialize the fields using WidgetData object's fields.
• Add only one field to each class which is of type WidgetData. Add getters to the three classes for only the relevant fields which delegate the get call to the WidgetData object to retrieve the value of the required field. This strategy will avoid duplicating the field values between WidgetData and the three widget classes and will probably save some memory.

This will cover the data part. Then if you feel that there is some commonality between the three widget classes, you can also create a base class which the three can extend and add any common methods or fields there.