views:

76

answers:

3

I have a set of classes which have similarities and differences. They derive from an interface, which defines the unique behaviour amongst these different classes, and a base class to call the common functionality in the several classes.

Is there a design pattern which governs how these sort of classes are created? Is it acceptable to use a base class and interface together for this design challenge (several classes all with the same logic + unique behaviour).

Thanks

A: 

Specification pattern will help you.

http://en.wikipedia.org/wiki/Specification_pattern

dario-g
+1  A: 

It's not clear to me what advantage your interface is giving you. Having classes that have some similar behavior and some different behavior is the essence of inheritance. You can put all the common behavior in a base class, then override the places where it needs to be different in each subclass.

I suppose if your language doesn't support abstract base classes, then having a base class and an interface would make sense. Can you give an example of what it is you're trying to do?


Your ABC can be something like:

public abstract class A
{
    public virtual void EverybodyDoesThisTheSame();
    public abstract void ThisIsDifferentForEach();
}

Then, in the derived classes, you just need to inplement ThisIsDifferentForEach(), and they can all use the inherited version of EverybodyDoesThisTheSame().

Mark Bessey
I'm using C# so yep I have abstract class support. In my case, I need to login to different web applications. The login process is the same for these different applications and I have modelled this as a base class which I call in the consumer of an interface (IWebApplication), and I have created an interface which contains the method to validate I have not hit any errors (which works differently in the different interface consumers).
dotnetdev
The base class doesn't need to be overriden for custom behaviour. The custom behaviour (completely different per interface consumer) is defined in the interface consumers. The generic functionality and unique functionality are seperate business processes and thus seperate methods,
dotnetdev
I edited my answer to expand on the abstract base class idea a bit. Honestly, it's a matter of taste. I usually think of interfaces as being suitable for "these objects share just this behavior, but are otherwise unrelated". For the case where a large amount of functionality is the same, I prefer the abstract base class.
Mark Bessey
A: 

If you don't use the base class for a common interface but common behavior only you don't need to derive from it but instead make it a member. That way you can assign behavior dynamically, if need arises.

public class behavior
{
   private void Login();
}

public class concrete1: behavior, IWebApplication
{
  public void Dosomething {Login; ... }
}

becomes

public class behavior
{
   public void Login();
}

public class concrete: IWebApplication
{
  private mBehavior;
  public concrete(behavior aBehavior): mBehavior(aBehavior) {if (aBhavior == 0) mBehavior = new behavior} ;

  public void Dosomething {mBehavior.Login; ... }
}

Now you derive from behavior if you want to change behavior implementation only.

Ozan
What about static classes for common functionality? What could that provide me with in benefit over a base class?
dotnetdev
I could modify my code to use your approach. mbehaviour is a static class variable it seems?
dotnetdev
You can make behavior and/or mbehavior static if behavior does not store state, but usually it does and then it needs to be instantiated for every object of concrete.
Ozan