Can we use Abstract class instead of interface

Question

i have started career as support developer but i have dream to get a job for S/W dev. i am learning OOPS with C#. often one thing bug me that is interface and abstract class usage. when to use interface and when to use abstract class. i search google on this topic but whatever the answer i browse and i saw all people try to explain what is abstract and interface but i am not after their definition rather i want see their real usage in real world program. here i like to highlight one code where interface is used but i think the full things can be design with abstract class too.

see the below code of repository design pattern where interface has been used if i expose repository as interface

public interface IEmployeeRepository
{
    Employee[] GetAll();
}

then advantage will be i could have as many implementations as i like as below

public class EmployeeRepositoryEF: IEmployeeRepository
{
    public Employee[] GetAll()
    {
        //here you will return employees after querying your EF DbContext
    }
}

public class EmployeeRepositoryXML: IEmployeeRepository
{
    public Employee[] GetAll()
    {
        //here you will return employees after querying an XML file
    }
}

public class EmployeeRepositoryWCF: IEmployeeRepository
{
    public Employee[] GetAll()
    {
        //here you will return employees after querying some remote WCF service
    }
}

see the above code which has one contract method GetAll() and who ever will extend the interface then they can provide their own implementation. that is the advantage but my question can i write abstract class instead of interface here ?

suppose i have one abstract class

abstract class AbsEmployeeRepository
{ 
   abstract public Employee[] GetAll(); 
}

now my all other repository will extend the abstract class AbsEmployeeRepository

and override the function GetAll() to give their own implementation.

now the question is if abstract class can solve my purpose then why we need interface in this scenario. where multiple inheritance is concern then interface will be preferred other wise we can complete job with abstract class.

looking for valuable comments and suggestions. thanks

Answer 1

You would use an abstract class, when you have

• Code to be shared.
• Default behaviour in methods, but want users of your class to be able to override it.

You would use an interface when

• There is no shared code.
• It needs to be applied to many objects, with no common base class.
• To make the definitions of public methods clearer and provide documentation.
• You wish the source code to be private.

Often you would use an abstract class (for shared code) together with an interface (for documentation).

Answer 2

Interface provides only "description" of your future classes, while abstract classes used when you need to have some "unfinished functionality". So if you want to have a class with some logic provided and some unimplemented functions - you should use abstract class, but if all the functions is not implemented - use interface instead.

Answer 3

You should use an abstract class IF all your implementation share a common code basis implementation. That means, the interface will guarantee, that all classes have the same members, but each one must have its own implementation for them.

If you have an abstract class as base, all inheriting classes share the same implementation unless they override it, which is in many cases not needed, often you need to implement only a hand full of members differently.

Interface - guarantee same members.

Abstract class - share common code basis.

Some nice thoughts about it got mentioned on my question for this, maybe this helps you out.

Answer 4

You use abstract classes when you need to provide more than just abstract members to implement but also some concrete member:

public abstract class A
{
     protected abstract void DoSomeCheck();

     public void DoStuff()
     {
          // You don't know how DoSomeCheck will be implemented but
          // you know a derived class must implement it
          DoSomeCheck();
     }
}

Alternatively, you use interfaces to define contracts that must be fulfilled by implementers in order to ensure that they can work together with your code:

// This car accepts any engine that implements IEngine
public class Car 
{
     public IEngine Engine { get; set; }
}

public interface IEngine 
{
     void Start();
}

There're many other use cases for both abstract classes and interfaces, but covering them would require a to compose a book instead of a simple answer. I still think that above explanation should give you the required hint to learn more about the topic.

Answer 5

can i write abstract class instead of interface here ?

Technically, yes you can. Practically, you shouldn't.

In this particular case implementation of the repositories is likely to be different. If implementation is different, an interface will declare desired behaviour in a clear way. Use of an abstract class can be justified, if the implementation was the same for all your repositories, or some methods where the same. Therefore allowing you to move otherwise duplicated code into one shared place.

Answer 6

In your particular case I'd rather not use either tailored interface or abstract class. There's IEnumerable<T> that does all you want, do not re-invent the wheel:

  public class EmployeeRepositoryEF: IEnumerable<Employee> {
    ...
  }

  public class EmployeeRepositoryXML: IEnumerable<Employee> { 
    ...
  }

whenever you want an array all you need do is ToArray():

 EmployeeRepositoryEF myRepo = ...

 Employee[] staff = myRepo.ToArray(); // <- just ask for array