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.

I find I tend to design class structures where several subclasses have nearly identical functionality, but one piece of it is different. So I write nearly all the code in the abstract class, and then create several subclasses to do the one different thing. Does this pattern have a name? Is this the best way for this sort of scenario?

Option 1:

public interface TaxCalc {
    String calcTaxes();
}

public abstract class AbstractTaxCalc implements TaxCalc {
    // most constructors and fields are here
    public double calcTaxes(UserFinancials data) {
        // code
        double diffNumber = getNumber(data);
        // more code
    }
    abstract protected double getNumber(UserFinancials data);
    protected double initialTaxes(double grossIncome) {
        // code
        return initialNumber;
    }
}

public class SimpleTaxCalc extends AbstractCalc {
    protected double getNumber(UserFinancials data) {
        double temp = intialCalc(data.getGrossIncome());
        // do other stuff
        return temp;
    }
}

public class FancyTaxCalc extends AbstractTaxCalc {
    protected double getNumber(UserFinancials data) {
        int temp = initialCalc(data.getGrossIncome());
        // Do fancier math
        return temp;
    }
}

Option 2:

This version is more like the Strategy pattern, and should be able to do essentially the same sorts of tasks.

public class TaxCalcImpl implements TaxCalc {
    private final TaxMath worker;
    public DummyImpl(TaxMath worker) {
        this.worker = worker;
    }
    public double calcTaxes(UserFinancials data) {
        // code
        double analyzedDouble = initialNumber;
        int diffNumber = worker.getNumber(data, initialNumber);
        // more code
    }
    protected int initialTaxes(double grossIncome) {
        // code
        return initialNumber;
    }
}

public interface TaxMath {
    double getNumber(UserFinancials data, double initial);
}

Then I could do:

TaxCalc dum = new TaxCalcImpl(new TaxMath() {
    @Override
    public double getNumber(UserFinancials data, double initial) {
        double temp = data.getGrossIncome();
        // do math
        return temp;
    });

And I could make specific implementations of TaxMath for things I use a lot, or I could make a stateless singleton for certain kinds of workers I use a lot.


So the question I'm asking is: Which of these patterns is superior, when, and why? Or, alternately, is there an even better third option?

share
4  
I don't know the name (or if there is one), but I would agree that it is a reasonable approach to design. Personally, I start with an interface and generate one or more abstract implementations based on my needs and finally one or more concrete implementations. From my perspective, each layer should make it easier to write the next, so by the time you reach the top of the food chain, you're focusing on writing the implementation details and not filling out the implementation to meet the contractual requirements of the parent classes (unless it's required)...IMHO –  MadProgrammer May 6 '13 at 1:12
1  
Several short classes are better than one long class (multiple ifs). Just be careful in this approach though, because if the AbstractDummy class is changed, all the subclasses will be forced to change. –  renz May 6 '13 at 1:16
    
@renz I almost always write my code to keep methods as short as possible, so I can solve problems like you describe by overriding methods –  durron597 May 6 '13 at 1:20
    
@MadProgrammer I just edited an entirely different second approach, does that one make more sense? –  durron597 May 6 '13 at 1:30
    
possible duplicate of Code Smell: Inheritance Abuse. See also: Composition vs. Inheritance –  gnat Jun 26 '13 at 17:28
show 1 more comment

migration rejected from stackoverflow.com Jun 29 '13 at 8:19

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gnat, Dynamic, Kilian Foth, Jalayn, Martijn Pieters Jun 29 '13 at 8:19

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

I would always prefer interfaces to abstract classes, composition to inheritance, and shorter code to longer code.

So, option 2 is the clear winner in my eyes.

share
add comment

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