0

I'm trying to improve my coding standards by implementing interfaces and abstract classes when necessary, however I would like to ask about practises regarding abstract classes.

I'm creating a web application and one aspect of the site I need to do some data processing, I have created an abstract class and it looks something like this.

public abstract class TestAbstractClass
{
  public abstract void doDataProcessing();
}

And I need to implement this 'doDataProcessing' method a few times throughout the application dependent on where the user is on my site, it will do VERY similar data processing, just with one or two different things.

For example:

User is on certain page:

public Page1Class: TestAbstractClass
{
  public override void doDataProcessing()
  {
    //do data processing
  }
}

User is on another page

public Page2Class: TestAbstractClass
{
  public override void doDataProcessing()
  {
    //do data processing but with slight change
  }
}

User is on another page

public Page3Class: TestAbstractClass
{
  public override void doDataProcessing()
  {
    //do data processing but with another change
  }
}

Would this be best practise? Or is it better just making one class, and just doing various conditional statements on what is being passed into the 'doDataProcessing()' method?

I feel if I do it using the method I have posted, I will be having a lot of duplicate code in these 3 classes, is that OK?

I hope this makes sense.

user3046756
  • 23
  • 5
  • 3
    You can have implementation in an abstract class/method btw. – Alex K. Jun 28 '17 at 15:03
  • 4
    Personally, I'd use an interface for this, unless there is a need for some code in the base class – phuzi Jun 28 '17 at 15:03
  • 2
    Possible duplicate of [Prefer composition over inheritance?](https://stackoverflow.com/questions/49002/prefer-composition-over-inheritance) – g t Jun 28 '17 at 15:04

2 Answers2

6

This feels like you need to decompose the solution a bit more. doDataProcessing sounds like it is something that could be broken into smaller pieces. There are high-level design patterns that could help you structure this.

If doDataProcessing is a similar thing but with small changes, then look at the Strategy pattern or the Decorator pattern.

Jeff Foster
  • 43,770
  • 11
  • 86
  • 103
  • The Strategy pattern looks good, but whenever 'doDataProcessing' is executed, I need to execute another method before hand in every circumstance, which is always the same. That is why I used an abstract class as I created the implementation for that method in there. What would you recommend in this situation? – user3046756 Jun 28 '17 at 15:27
  • A method before hand (which is always the same)? I might do something like `public void doDataProcessing() { doTheAlwaysThing(); _internalDoDataProcessing(); }` (rename the version of `doDataProcessing` to something internal and make the public version the real version). – Jeff Foster Jun 29 '17 at 05:50
0

If you are not going to have any implementation in the base doDataProcessing then just go with an interface as @phuzi recommended. Abstract classes are best used if you have some logic that is exactly the same in most cases, and in odd scenarios you can override and/or extend the base logic in the inherited classes.

EDIT

From the information you gave me I would probably do the following:

public abstract class TestAbstractClass
{
  public void Process()
  {
     MethodThatGetsCalledEveryTime();
     doDataProcessing();
  }

  public virtual void doDataProcessing()
  {
      // can add frequent logic here
  }

  protected void MethodThatGetsCalledEveryTime()
  {
      // do stuff here
  }
}

this way you can ensure that the "MethodThatGetsCalledEveryTime" will always be called, and if you add additional logic to doDataProcessing that will run as well from the appropriate place.

Igor Meszaros
  • 2,081
  • 2
  • 22
  • 46