Skip to main content
2 of 2
list formatting
svick
  • 10.1k
  • 1
  • 39
  • 52

Interface Dependencies or Abstract Classes

I have a decision to make and I am wondering what would be the better solution. I am refactoring an older application and intend to really get into the nuts and bolts of it.

There are 8 report types currently and one of the modifications are to allow different reports to be "saved" in different ways. My two thoughts on it were

  1. Have an Abstract Class with an abstract save method, then each report type can define its own way of doing things. Possibly have other abstract classes inheriting from that one, each implementing a virtual Save() method. Then the report classes can inherit from the one with the relevant save mechanism.

  2. Have a report interface, which has a method signature like

     void Save(ISaveMechanism saveMechanism);
    

Then have an interface with a Save() method, then each report type can use saveMechanism.Save(); and just use the concrete implementation required.

Would either solution cause more issues/drawbacks than the other? This project doesn't currently have any associated unit tests but if given time, it would be good to add some later.

Lotok
  • 1.8k
  • 2
  • 17
  • 28