File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes strategy vs. abstract class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "strategy vs. abstract class" Watch "strategy vs. abstract class" New topic

strategy vs. abstract class

guenter krannich

Joined: Sep 15, 2003
Posts: 24
I have several classes which differ only in one method, so I think of either using an abstract class and have several specialized classes which only implement the specific method differently or have several implementations of a command that is passed to the one common class.
Are there significant differences between the two approaches? pros and cons?
Campbell Ritchie

Joined: Oct 13, 2005
Posts: 46409
You actually do both.
You have

+myMethod: void (abst)
+myOtherMethod: void

and there you have an abstract class.
You can't write proper UML on these boards, but you use italics for abstract classes.

Now you have a concrete class:

MyConcreteClass extends MyAbstractClass
-------{you can have additional fields if you wish}
+myMethod: void

and make myMethod concrete. When you code an abstract method, you write it like this

. . . and when you have it in a concrete (or ordinay class), you code it normally. You can't have an abstract method in an ordinary class, and every time you create an ordinary class from an abstract class, you must implement every abstract method, but they can all be different. (Keep the same signature, however.)

Now what you can do is use the superclass (even though abstract) in a declaration of an object, like this,and you can call the method on every object on every subclass of MyAbstractClass, just like this:-Just the same as for any other object.

Because every subclass of an abstract class has the same method signature, you can call a method like that from every object of every subclass, and it will work, but can be set up differently every time.

If you want a method which is the same in every instance, put an ordinary method into the superclass (you can have concrete methods in an abstract class), and you call it normally, and it will work the same in every subclass.

That's how you use the two different approaches.
Dave Wingate
Ranch Hand

Joined: Mar 26, 2002
Posts: 262
I'd suggest that you first consider the "different commands" that you'd create in that single class. If each of those commands is the same conceptual operation, varying slightly for different contexts, then you'd probably be better of subclassing. Your code will be more easily manintained if the same operation has the same method name through out subclasses. This prevents other programmers from having to select the "right" method from a single class; something they're bound to get wrong.

Fun programming etcetera!
guenter krannich

Joined: Sep 15, 2003
Posts: 24
ok, just to make sure I got it right:
I'm talking about a bunch of panels that look and behave the same, but the the underlying list models get their data in different ways, so the programmer always has the choice/problem to decide
a. which command he has to pass to the GenericPanel or
b. which SpecificPanel he has to use
Is there a difference?
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Yes, of course there is a difference!

As an aside, your "abstract class" approach sounds similar to the Template Method design pattern.

Template Method is simpler than Strategy: You need one class hierarchy less, instantiating the object is simpler etc.

Strategy, on the other hand, is more flexible: you can exchange the Strategy used after the object was created, the Strategy is better decoupled so that changes to the base class can't ripple through to it, Strategies are easier to reuse etc.

There is no hard and fast rule for which one should be used in which situation (I'm sure Tony will disagree... ). Good designers are by a big amount driven by gut feel, educated by a lot of experience. If you don't have that experience, my advice would be to start with Template Method, until you know you need the flexibility provided by Strategy.

See also

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Dave Wingate
Ranch Hand

Joined: Mar 26, 2002
Posts: 262
Both approaches will work fine for your purpose.

I would tend to go with approach b because it follows the metaphor of the language you're working in -- i.e. that we build software by creating classes that participate in inheritance relationships. Also, note that the more times you want to extend/specialize, the less attractive option a becomes.

For example, consider the situation in which you've created a FinancialPanel and realize that you also need a FilteredFinancialPanel in which certain records are removed. With option a, you'd have to read the code (in the Generic panel class) to find out the relationship between the two panels. With option b, other programmers can quickly understand (jsut by reading class names and "extends" clauses) that one panel is an extension of the other.
guenter krannich

Joined: Sep 15, 2003
Posts: 24
thanks Ilja, I'll use the Template Method.
I agree. Here's the link:
subject: strategy vs. abstract class
It's not a secret anymore!