1

Possible Duplicate:
Interface vs Abstract Class (general OO)

In one of the MSDN article following line is mentioned

Interfaces cannot specify new members in later versions while abstract classes can add members as needed to support additional functionality.

I picked this sentence from here. You can read the same sentence in paragraph 3.

I have a confusion, sorry in advance for in case I am missing something.

Once the Abstaract Class or Interface is declared and then any Derived class is inheriting the methods, in either case, all the methods should be overridden. Otherwise compilation error will come.

Your comments?

Community
  • 1
  • 1
Pankaj
  • 8,971
  • 23
  • 105
  • 242

4 Answers4

4

Once the Abstaract Class or Interface is declared and then any Derived class is inheriting the methods, in either case, all the methods should be overridden. Otherwise compilation error will come.

No, for an abstract class only the abstract methods need to be overridden. You can add non-abstract methods with no errors.

For example, version 1:

public abstract class FooBase
{
    public abstract void Bar();    
}

public class FooImpl : FooBase
{
    public override void Bar() {}
}

Now introduce a new non-abstract method in FooBase for version 2:

public abstract class FooBase
{
    public abstract void Bar();   

    public void NewMethod() {}
}

... and there's no problem.

Note that for company internal code, where all the code which is going to use the API is rebuilt at the same time, this is often not a problem at all, with either interfaces or abstract classes. If you want to add a method to an interface, you can do so as you can upgrade all implementations at the same time.

It's really when you don't have control over the whole code base that you need to be careful.

Jon Skeet
  • 1,261,211
  • 792
  • 8,724
  • 8,929
  • What's the benefit of adding a non-abstract method in real time? Can you give an example ? – Pankaj Nov 28 '12 at 17:57
  • @PankajGarg: What do you mean by "in real time"? It provides more functionality that callers can use, without imposing any more burden on subclasses. Example: `Stream.CopyTo` in .NET 4. – Jon Skeet Nov 28 '12 at 18:02
  • Actually, I want to know, in which situation I should have Non Abstract method in abstract class? Actually I never done this kind of implementation before. Thanks for your time... – Pankaj Nov 28 '12 at 18:06
  • @PankajGarg: I've given you an example - Stream is an abstract class, and CopyTo is a non-abstract method. It's a convenience method which *uses* the abstract methods in the class. – Jon Skeet Nov 28 '12 at 18:08
  • @PankajGarg: Not really - that's a very vague question, and isn't really related to the versioning you brought up in the original question. – Jon Skeet Nov 28 '12 at 18:16
1

an class implementing an interface MUST implement all methods and properties defined in the interface.

when inheriting from an Abstract class, you MUST implement/override all the Abstract members, but any non-abstract members will be inherited just as when you inherit from a concrete class.

Frank Thomas
  • 2,231
  • 12
  • 26
  • Why should somebody use Non-Abstract methods in Abstract class ? – Pankaj Nov 28 '12 at 18:08
  • so you can create a partial implementation of a subset of members. if all your child classes will use the same specification of a single method, but vary on other methods in spec but not name, then you can define the non-abstract method in the abstract class instead of having to implement the specification in each and every child class. – Frank Thomas Nov 28 '12 at 19:48
0

Implementing an interface forces you to override its methods - inheriting a class however gives you a choice. Only abstract methods needs to be overriden. The MSDN excerpt points out that the price of a strict interface contract can prove to be expensive later on, when all implementors will need to implement the added methods. Using a class parent with virtual methods let you decide later on whether you need a specialization.

mhoff
  • 383
  • 3
  • 11
0

When you inherit from Interfaces, you must implement all members of that interface. But you can expand on the interface as you deem fit. You can also inherit multiple interfaces. Valid Example:

public interface IPerson
{
    string FullName { get; set; }
    string SSN { get; set; }
}

public interface IPersonDBContext
{
    void Save(IPerson person);
}

public class PersonData : IPerson, IPersonDBContext
{
    // Implements IPerson FullName
    public string FullName { get; set; }

    // Implements IPerson SSN
    public string SSN { get; set; }

    // Implements IPersonDBContext Save()
    public void Save(IPerson person)
    {
        // Code to save the IPerson instance to the DB...
    }

    // Added method, not included in any interface...
    public void Validate(IPerson person)
    {
        // Code to validate the IPerson instance...
    }
}

Now, for Abstract classes, you can include concrete methods that can be inherited, but also specify some methods that must be overridden. However, note, you cannot have more than one Base Class (and an Abstract Class is still a class...) So you can't mix two abstract classes like you can an interface. Example:

public abstract class Person
{
    public string FullName { get; set; }
    public string SSN { get; set; }

    public abstract void Save();
}

public class PersonData : Person
{
    // Implements Abstract Person Save() Method
    public override void Save()
    {
        // Save logic here...
    }

    // Non-inherited member...
    public void Validate()
    {
        // Access properties of the base class (Abstract Person)
        this.FullName.ToString();
        this.SSN.ToString();
    }
}

Lastly, and most powerfully, you can mix a single abstract base class with as many interfaces as you want... So, If I kept the Abstract class Person, from example 2, and the Interface IPersonDBContext from example 1, I could do this:

public class PersonData : Person, IPersonDBContext
{
    // Implements Abstract Person Save() Method
    public override void Validate()
    {
        // Access properties of the base class (Abstract Person)
        this.FullName.ToString();
        this.SSN.ToString();
    }

    // Inplmenets IPersonDBContext Save()
    public void Save(Person person)
    {
        // Save logic here...
    }

    // Non-inhereted method
    public void Clone(Person person)
    {
        // Logic to make a member-wise clone.
    }
}

Hope that helps...

EtherDragon
  • 2,629
  • 1
  • 16
  • 24
  • 1
    `public override void Validate()` should it be `public override void Save()` ? – Pankaj Nov 28 '12 at 18:23
  • @PankajGarg Correct. http://www.dotnetspark.com/kb/300-interfaces--factory-pattern--decoupled-architecture.aspx here is a great article on how to use interfaces and the factory pattern to decouple your dependancies. Any time a class is dependant on a base class it risks being more volitile as changes to the base class may require reworking the derived class, propagating changes throughout the whole application. Interfaces clearly set expectations up-front, and you can know (in advance) what will be impacted by a change to any interface. – EtherDragon Nov 28 '12 at 18:25
  • Can you give us knowledge about De-Coupling while differentiating between Interface/Abstract Class point of view...? – Pankaj Nov 28 '12 at 18:28
  • Generallt, if you use Test Driven Development, you will know if your code base is decoupled if you can do targetted unit tests across all code within a particular class without requiring a lot of other class instances for the test. – EtherDragon Nov 28 '12 at 18:32