Subclass only have methods without variables

Question

Is it ok to have subclass which does not declare its own variables (instance variables) and inherits from super class or base class? It has methods and there are some common methods which it overides but do not have variables of its own.

Is it ok to have subclasses which defines behavior only or I am missing something? I want to divide in subclasses to separate logic of my classes. I have Medication class and I want to subclass to DailyMedication , WeeklyMedication but I have all my instance variable in Medication as I do not have any specific for these classes. I want to make subclasses to divide logic as I have too much if conditions in my code.

MedicationEntity
name
dose
weekdays    //in case of daily and monthly this is null 
monthdays   //in case of weekly and daily this is null
frequencyType  //Daily or weekly or monthly
etc

EDIT: I want to make subclasses because these all classes have diffrent logic.I have enum of frequency(for Daily,Weekly etc) in my Medication class and this makes worse as i have to put all the checks in my code for these frequency type as if frequency is that than do that and if daily than do that as now i want to remove these switch conditions.

1)Also please suggest any good idea as weekdays is null if frequency is daily or monthly.But i need to send null to server.So where i can put weekdays if i subclass as it is not null only in case of weekly frequency but as i have to send null to server in request for all other frequencies.Should i put weekdays in subclass if yes than how i send null to server if frequency is daily as DailyMedication have no information about weekdays.

Answer 1

Having three separate classes might make sense if you know you're going to add some special members to some of these subclasses and you just haven't gotten around to it yet (but you're going to really soon, right?).

Normally, I'd agree with the senior developer: This seems like an unecessary complication. Could you create an enumeration called Frequency and use that to determine which type of Medication you're dealing with, something like this pseudo-code:

Enum MedicationFrequency{MONTHLY, DAILY, WEEKLY, HOURLY}

class Medication
{
    private MedicationFrequency frequency;
    ...
}

I suppose if you really want to keep the different implementations completely separate, you could try to inject specific algorithms into the Medication instances. Maybe something like this:

Interface MedicationProcess
{
   public void doSomething();
   public String getWhen();
   public MedicationFrequency getFreq();
}

class WeeklyMedProcess implements MedicationProcess
{
   String weekdays;
   public MedicationFrequency getFreqy() { return MedicationFrequency.WEEKLY;}
   public String getWhen() { return weekdays; }
   //...
}

class DailyMedProcess implements MedicationProcess
{
   public MedicationFrequency getFreqy() { return MedicationFrequency.DAILY;}
   //...
}

class MonthlyMedProcessimplements MedicationProcess
{
   String monthdays;
   public MedicationFrequency getFreqy() { return MedicationFrequency.MONTHLY;}
   public String getWhen() { return monthdays; }
   //...
}

class Medication
{
    private MedicationProcess someProcess;
    private String updateColumnName;

    public void setUpdateColumnName(String s)
    {
        this.updateColumnName= s;
    }

    public void setProcess(MedicationProcess p)
    {
        this.someProcess = p;
    }

    public doMedicationThing()
    {
        this.someProcess.doSomething();
    }
}

Doing this in Java, You'd have a Spring configuration that might look like this:

<bean id="dailyMedProc" class="DailyMedProcess/>
<bean id="weeklyMedProc" class="WeeklyMedProcess/>

<bean id="medication1" class="Medication">
    <property name="process" ref="dailyMedProc/>
    <property name="updateColumnName" value="weekdays"/>
</bean>

<bean id="medication" class="Medication">
    <property name="process" ref="weeklyMedProc/>
    <property name="updateColumnName" value="monthdays"/>
</bean>

To answer your quesion about weekdays and monthdays, there are many ways to do this and it's not very clear from your question just what weekdays and monthdays are. Since you show them to be single variables, I'll assume they are just comma-separate strings.

It sounds like you also have columns in some table named weekdays and monthdays which need to be set to null if there is no value. Since you already know the frequency of the Medication (via its someProcess.getFreq), you know which field to set to null. The implementors of MedicationProcess can be required to implement getWhen, which will return the comma-separated list of days/month-days. With these two pieces of information, you can easily update the correct columns.

Having Medication have knowledge over what to do when specific MedicationFrequencies are encountered does break the design pattern a little bit. It's not great, but it's a simple solution.

If you don't like that, you could include the column name that should be updated for a specific instance of Medication. Only slightly better - I don't like mixing that sort of low-level data access into such classes, but I haven't seen the rest of your design, so maybe it's OK here...

Another option would be to have the MedicationProcess do its own database insert/update. This is a little trickier and I can't really give any concrete examples of how to do this without knowing the details about your schema, though I think this would be the best solution, if you can implement it.

There are other ways to implement the strategy pattern, depending on the tools and frameworks available to you.

Also, see: https://stackoverflow.com/questions/17721623/advantages-of-using-strategy-pattern-in-php The question is PHP-specific, but the answer is not.

Answer 2

I can see this both ways:

• make the sub classes: If the sub classes have truly different logic, then by all means that logic should be separated even if there are no instance variables. Think of the classic OOP "hello world" - a drawing program with Shape, and different subclasses for Square and Triangle. CalculateArea() would be different, but they'd both work on height and width.
• keep them together: In your example, I might have one class Medication with a property that represents the idea of an Interval or Duration. In an ideal world you would have just one set of logic that would operate on an "Interval" without caring very much if it was every 1 hour, every 24, or every 168.

Without more information my suspicion is that your senior dev is correct for your particular situation. (That's how senior devs get to be senior devs - by being right more often than they're wrong).

I think you're right to want to remove all that conditional code. The question is whether it's better to hide the conditions in subclasses or to re-think the process so the interval becomes just a simple parameter.

Look at this another way: what would you have to do if your boss asked you to support a new time period (Daily, Weekly, Monthly, Every17Hours, Every3.5Days, etc.)? Can you code your methods so instead of looking at enums you can just work off the interval?

It may be necessary to talk to the senior dev & see what he has in mind. It's possible his concern is based on an insufficient grasp of the issues.

Answer 3

Sometimes it makes sense to have a class hierarchy in which derived classes differ only in implementation methods from base classes. In particular, if you have a hierarchy of objects that have the same inputs, the same outputs, and interact in identical ways with the rest of the system, but nevertheless have substantially different implementation logic, you can consider using a method-only hierarchy.

For instance, consider CAD software which allows users to add "measurement" objects to its database. Each measurement entity holds a persistent reference to one or more geometric entities, and outputs a real number (the measurement) in a specified unit system. Now, there might be many different measurement algorithms -- arc length, max/min radius of curvature or extrema along a vector of selected curves; surface area or perimeter of selected faces; and so on. Each release of the CAD system is likely to add new measurement types. But they should all behave identically to the rest of the system. E.g. if geometric entities are copied and pasted, their measurements should be copied alongside with references updated. Or if a geometric entity is highlighted, perhaps its measurements should be queried from the database and shown in a window. As long as there is substantial identical code dealing with the generic aspects of measurement entities, a method-only class hierarchy (probably mirroring an interface hierarchy) is a sensible implementation.

In your case, however, you are creating a top-level class which is the union of other classes with substantially different inputs or outputs, like so:

public abstract class Top
{
    public abstract double? Sub1Properties { get; }

    public abstract double? Sub2Properties { get; }
}

public class Sub1 : Top 
{
    double data = 24.0 // or whatever.
    public override double? Sub1Properties
    {
        get
        {
            return data;
        }
    }
    public override double? Sub2Properties
    {
        get
        {
            return null;
        }
    }
}

This, I think is unfortunate. Consumers of your classes will likely write code like so:

        if (top.Sub1Properties != null)
        {
            // DO something
        }
        else if (top.Sub2Properties != null)
        {
            // Do something
        }

Now imagine that, tomorrow, you need to add a third subclass:

public abstract class Top
{
    public abstract double? Sub1Properties { get; set; }

    public abstract double? Sub2Properties { get; set; }

    public abstract double? Sub3Properties { get; set; }
}

All those if statements will need to be updated. This is old-time procedural logic, and is IMHO an anti-pattern. In your case, if you need to add a new dosing regimen (bi-monthly) in a later software release all those if statements would need updating.

In your case, I might suggest dividing up "Medication" and "Dosing Schedule" into separate objects/tables, with each medication having a link to its appropriate schedule. Then adding a new regimen would require only a new entry in the table. I might also represent frequencies in a generic way to the outside world, for instance by using a TimeSpan. If there is substantial logic specific to each regimen, it could be represented as a hierarchy of classes, as long as there is a generic representation to the outside world for all the data therein.

Answer 4

Take 2.

I understand that you have the following constraints:

1. You can't change the underlying data model on the server at all. The server-side representation of "MedicationEntity" has hardcoded fields corresponding a small number of possible sets of dosing schemes, and you need to be able to translate from & to this model.

2. The various dosage schemes can't be generalized as a set of standard time intervals. E.g. "M, Th, S" might be a valid weekly dosage schedule. This lack of perfect uniformity kills the idea of representing all the frequencies as a simple TimeSpan.

In that case, I would suggest that your "MedicationEntity" class should completely hide the server-side dosage frequency fields. It must needs remember them internally, since that is what is stored on the server, but it should never present them as public properties. Instead it should have some property "DosageFrequency" which returns an instance of a class implementing an interface "IDosageFrequency" (here I am using c# because I am most familiar with it):

public interface IMedicationEntity
{
    string Name { get; }

    double Dose { get; }

    string Units { get; } // 

    IDosageFrequency DosageFrequency { get; set; }
}

The "IDosageFrequency" interface could encapsulate all the business logic for each dosage frequency and present them in a neutral manner, e.g.:

public interface IDosageFrequency
{
    string Name { get; }

    string Description { get; } // Localized for presentation in the user interface.

    string FormattedPromptString(IMedicationEntity medication); // E.g.: string.Format("{0} {1} of {2} three times a week.", med.Dose, med.Units, med.Name)

    DateTime NextDoseTime(DateTime now);

    TimeSpan DoseTimeRequiredAccuracy { get; }

    IEnumerable<DateTime> DoseTimesBetween(DateTime start, DateTime end);

    // etc
}

You could then implement this interface with different classes corresponding to each basic dosage scheme. You could also use the abstract factory pattern to maintain libraries of standard DosageFrequency objects to present in the user interface, to allow end users to select a new dosage scheme for some pre-existing or new medication.

This would leave you with only two nasty switch statements, both inside your "MedicationEntity" class:

1. Constructing the appropriate IDosageFrequency from the stored fields from the server, AND

2. Selecting the appropriate server fields when a new IDosageFrequency object is set.

By hiding the sever-level hardcoded dosage schemes, this pattern (is there a name for it?) could keep the switch statements from growing out of control while also avoiding the need to create different medication class types for different dosage schemes.

Update: incidentally, I just noticed a potential pitfall with your scheme of creating a class hierarchy for the "MedicationEntity: objects. If you need to implement the ability to change the dosage scheme for a pre-existing MedicationEntity, you will need to immediately locally replace the existing MedicationEntity with an instance of a different subclass, e.g. DailyMedicationEntity -> WeeklyMedicationEntity; if you didn't you would be unable to locally work with the new settings. But the server side representation of the MedicationEntity would not need to be deleted and recreated, which means you temporarily could have obsolete, replaced MedicationEntity instances floating around in your client referring to still-extant database entities. This, I suspect, might Cause Problems.