Abstract Class & Interface: Two Villains of Every Interview

This article is the second part of the series “Abstract Class & Interface: Two Villains of Every Interview” and explains the important key points of interfaces.

Introduction to Interface

In my first article, I received a lot of feedback, some positive, some negative and the neutral but one question everyone asked is why I implied they are villains. I just want to clarify that I did not intend to portray them as villains. These are the most important concepts in programming and without them we cannot get better code efficiency.

Mostly in every interview, the first question is, "What is the difference between an Abstract Class and an Interface" and your entire interview depends on the answer to this question. Remember, “The first impression is the last impression”. So, these concepts are not villains but their role in an interview surely is. Enough about the critics, let's move to the next part of the series: interfaces.

An interface is the most important element of a software project and without it, a project is incomplete. Many wouldn't agree with me and debate that. Yes, it is a debatable question whether or not to use an interface. If yes, then how? In this article, I'm going to explain the important key aspects of interfaces. Like my previous article about abstract classes, I used the same approach of “What, Why and How” in this article and tried to explain it in the simplest possible way.

Roadmap

If you're reading this article for the first time, I request you to go for Part 1 of this series and then return later to this article. Here is the road map of the series of articles under the title “Abstract Class & Interface: Two Villains of Every Interview”:

Abstract Class & Interface: Two Villains of Every Interview – Part 1 [Abstract Class]

Interface

What an interface is

In the real world, an interface means a medium to interact with something. To be precise, it's a point where two systems, subjects, organizations and so on meet and interact. There are a few rules for the interaction to be done. Suppose you are going for an interview of Programmer Profile. The interview is only possible if the interviewer and you speak the same language. Moreover, you and the interviewer have the same skill set of programming languages to discuss upon.

Similarly, in the programming world, an interface means a contract to interact with multiple code modules. If a class wants to communicate with an interface, it must implement it and define its members. Consider it like the interviewer's question and you need to answer it correctly, if you want the job.

The MSDN Library defines the interface like a pure abstract class. An interface contains only the signatures of methods, properties, events, or indexers. It has no implementation of its own and can only be implemented by a class or a struct. Any of the two that implement the interface must provide the definitions to members specified in the interface. It is like a contract for all the derived classes to follow.

An interface is declared using the interface keyword. interface members are implicitly public and abstract, so we cannot prefix any access modifiers to it. An interface cannot contain fields, constant members, constructors, destructors and static members.

Why we need an interface

An interface is not a class. It contains only method signatures. It has no implementation on its own and cannot be instantiated. Its implementation logic is provided by the classes that derived from it. An interface is mostly considered to be a pure abstract class. However, there is the advantage of using an interface over an abstract class; that is "Multiple Inheritance Support". In C#, two classes (either abstract or concrete) cannot be inherited by the same derived class. It causes ambiguity in the derived class if both have the same method signature. We can do multiple inheritance in C# using interfaces.

An interface plays a vital role in the Service Oriented Architecture (SOA). In WCF, we use interfaces to define Service Contracts. A single class can implement any number of Service Contract Interfaces. It is generally accepted as the best practice to do so. However, we can also use classes for Service Contracts.

Most of the Design Patterns and Principles are based on interfaces rather than class inheritance. Some of the examples are Builder Design Pattern, Factory Pattern, Interface Segregation Principle and so on.

How to define an interface

Suppose we need to define a class for a Smart Phone. The class can have members like OS, AppStore and Call. The Smartphone can be either Android based or iOS based and cannot be both. There is no common functionality between an Android and iOS Smartphone, so we don't need to provide any default functionality. One approach is to make the SmartPhone class abstract and also all its members abstract. This approach works fine and several concrete classes like Samsung, Apple, HTC can inherit from it.

Now, after a few days Apple wants to add a Touch ID feature to its Smartphone. You can add TouchID as an abstract method in your abstract base class SmartPhone. But what if HTC doesn't want that feature and neither does Samsung? So, the TouchID method cannot be placed inside the abstract class SmartPhone. An alternative is to define another abstract class Features and add the TouchID method to it. This is also a bad idea since C# doesn't support inheritance of multiple classes (abstract or concrete) into a derived class.

In this situation, an interface is useful and plays a vital role in solving the problem. An interface provides only the method definitions, just like an abstract class, but can be useful in multiple inheritances. You can make the Features class an interface and add the TouchID method to it. It provides only the method signature and whichever class inherits it can implement it in its own way. It is also completely valid for a class to inherit more than one interface in C#. Also, we can make the SmartPhone class an interface instead of an abstract class. It is better instead of making a pure abstract class, we can use interfaces.

Note: The example is not a best one, but I think it gets the point across. It is just for the sake of understanding interfaces.

Let us consider the example discussed above and create a Console Application for it. Open Visual Studio and add a new console project as "InterfaceDemo".

console application

By default, it gives a class named Program with a Main method in it for code execution. Let's create an abstract class SmartPhone and define OS and AppStore abstract methods in it. We can create an abstract class by putting the keyword "abstract" before a class definition. If you're not familiar with abstract classes, please go to the Part 1 of this series.

using System;
namespace InterfaceDemo
{
//Abstract Class SmartPhone with only abstract methods in it
abstract class SmartPhone
{
public abstract void OS();
public abstract void AppStore();
}
class Program
{
static void Main(string[] args)
{
}
}
}

Now define the concrete classes Apple and Samsung that inherits from Smartphone and provides the definitions to the abstract methods OS and AppStore.

using System;
namespace InterfaceDemo
{
//Abstract Class SmartPhone with only abstract methods in it
abstract class SmartPhone
{
public abstract void OS();
public abstract void AppStore();
}
class Apple : SmartPhone
{
public override void OS()
{
//Some Implementation Here
}
public override void AppStore()
{
//Some Implementation Here
}
}
class Samsung: SmartPhone
{
public override void OS()
{
//Some Implementation Here
}
public override void AppStore()
{
//Some Implementation Here
}
}
class Program
{
static void Main(string[] args)
{
}
}
}

If we compile the code now, it works fine. Our SmartPhone class is implemented by two different concrete classes Apple and Samsung and defined depending on them. Now, let us suppose Apple wants to provide TouchID features to its Smartphone. We can add another abstract method TouchID in the SmartPhone class and let Apple inherit it and implement it.

using System;
namespace InterfaceDemo
{
//Abstract Class SmartPhone
abstract class SmartPhone
{
public abstract void OS();
public abstract void AppStore();
//TouchID method meant only for Apple Class
public abstract void TouchID();
}
class Apple : SmartPhone
{
public override void OS()
{
//Some Implementation Here
}
public override void AppStore()
{
//Some Implementation Here
}
//Implementing the TouchID feature
public override void TouchID()
{
//Some Implementation Here
}
}
class Samsung: SmartPhone
{
public override void OS()
{
//Some Implementation Here
}
public override void AppStore()
{
//Some Implementation Here
}
}
class Program
{
static void Main(string[] args) { }
}
}

The Apple class inherits the TouchID method and provides a definition to it. Let's compile the code now and see what happens.

error

It throws an error saying that the Samsung class doesn't implement the TouchID method. By the definition of abstract class, any class implements it must provide definitions to all its abstract members. The TouchID method is meant only for the Apple class and the Samsung class doesn't want to implement it. It clearly seems that our approach is wrong since the TouchID method cannot be placed in the SmartPhone abstract class.

An alternative approach is to define another abstract class Features and define the TouchID method to it. This approach seems fine since whatever class inherits Features can implement the TouchID method.

using System;
namespace InterfaceDemo
{
//Abstract Class SmartPhone
abstract class SmartPhone
{
public abstract void OS();
public abstract void AppStore();
}
//Abstract Class Features for TouchID method
abstract class Features
{
public abstract void TouchID();
}
//Apple Class inherits both SmartPhone and Features
class Apple : SmartPhone, Features
{
public override void OS()
{
//Some Implementation Here
}
public override void AppStore()
{
//Some Implementation Here
}
//Implementation of TouchID method in Apple Class
public override void TouchID()
{
//Some Implementation Here
}
}
class Samsung : SmartPhone
{
public override void OS()
{
//Some Implementation Here
}
public override void AppStore()
{
//Some Implementation Here
}
}
class Program
{
static void Main(string[] args)
{
}
}
}

Let's compile the code and see what happens.

It again throws an error saying we cannot have multiple base classes in a derived class. This is called Multiple Inheritance of classes and is not allowed in C#. So, our second approach also fails to implement the TouchID method. This is where an interface is useful and helps to solve the "Multiple Inheritance" issue in C#. We can define both the SmartPhone and Features as interfaces and let the classes implement them as they need to. We can also have more than one interface in a class. This is the only way to do multiple inheritance in C#.

Let's re-create the same project using interfaces. We can create an interface using the keyword interface. It is considered a good practice to prefix "I" before the interface name, however the point is arguable and the choice is yours.

using System;
namespace InterfaceDemo
{
interface ISmartPhone //Definition of Interface
{
public void OS();
public void AppStore();
}
class Program
{
static void Main(string[] args)
{
}
}
}

We have defined the interface ISmartPhone with the method signatures OS and AppStore in it. If we compile the code now, it throws an error straightaway.

It says we cannot prefix public modifiers with method signatures. In fact, no access modifier is allowed with interface methods. Interface methods are implicitly public in C# because an interface is a contract meant to be used by other classes. Moreover, we must declare these methods as public in derived classes, when we provide implementations to these methods. Also, we cannot declare these methods as static.

using System;
namespace InterfaceDemo
{
interface ISmartPhone //Definition of Interface
{
static void OS();
static void AppStore();
}
class Program
{
static void Main(string[] args)
{
}
}
}

If we compile the code, it again gives us an error.

error list

Let's define the interface methods without any access modifier and create a concrete class Apple that inherits the ISmartPhone interface and provides definitions to its members.

using System;
namespace InterfaceDemo
{
interface ISmartPhone
{
void OS();
void AppStore();
}
class Apple: ISmartPhone
{
//OS Method Implementation
public void OS()
{
Console.WriteLine("OS Method: The OS of this Smartphone is iOS8");
}
//AppStore Method Implementation
public void AppStore()
{
Console.WriteLine("AppStore Method: The Application Store of this Smartphone is iTunes");
}
}
class Program
{
static void Main(string[] args)
{
}
}
}

An important point that should be noted here is that whenever we implement interface members in derived classes, the access modifier must always be public otherwise it throws an error. If we write a protected modifier instead of public to the OS method, the compiler throws an error.

using System;
namespace InterfaceDemo
{
interface ISmartPhone
{
void OS();
void AppStore();
}
class Apple: ISmartPhone
{
//OS Method kept as Protected
protected void OS()
{
Console.WriteLine("OS Method: The OS of this Smartphone is iOS8");
}
//AppStore Method Implementation
public void AppStore()
{
Console.WriteLine("AppStore Method: The Application Store of this Smartphone is iTunes");
}
}
class Program
{
static void Main(string[] args) { }
}
}

In the code above, I replaced the access modifier of the OS method from public to protected. Let's compile the code and see what happens.

compile error list

Yes, it throws an error saying that the Apple class cannot implement the OS method because it is not public. So, always keep your method implementations public in derived class. We can define another concrete class Samsung that also implements the interface ISmartPhone and provides definitions to its members.

using System;
namespace InterfaceDemo
{
interface ISmartPhone
{
void OS();
void AppStore();
}
class Apple: ISmartPhone
{
//OS Method Implementation
public void OS()
{
Console.WriteLine("OS Method: The OS of this Smartphone is iOS8");
}
//AppStore Method Implementation
public void AppStore()
{
Console.WriteLine("AppStore Method: The Application Store of this smartphone is iTunes");
}
}
class Samsung : ISmartPhone
{
//OS Method Implementation
public void OS()
{
Console.WriteLine("OS Method: The OS of this smartphone is Android");
}
//AppStore Method Implementation
public void AppStore()
{
Console.WriteLine("AppStore Method: The Application Store of this smartphone is Google Play");
}
}
class Program
{
static void Main(string[] args) { }
}
}

This code works fine since various concrete classes implement the interface and provide definitions to its members in their own way. Now if the Apple class wants to implement TouchID features, it can easily be done by defining another interface IFeatures. The Apple class can simply inherit the interface and implement the TouchID functionality to its class. This is the case where an interface is useful instead of an abstract class.

using System;
namespace InterfaceDemo
{
interface ISmartPhone
{
void OS();
void AppStore();
}
//New Interface meant only for Apple Class
interface IFeatures
{
void TouchID();
}
class Apple: ISmartPhone, IFeatures
{
//OS Method Implementation
public void OS()
{
Console.WriteLine("OS Method: The OS of this smartphone is iOS8");
}
//AppStore Method Implementation
public void AppStore()
{
Console.WriteLine("AppStore Method: The Application Store of this smartphone is iTunes");
}
//TouchID Method Implementation
public void TouchID()
{
Console.WriteLine("TouchID Method: This method provides Touch/Gesture control features.");
}
}
class Samsung : ISmartPhone
{
//OS Method Implementation
public void OS()
{
Console.WriteLine("OS Method: The OS of this smartphone is Android");
}
//AppStore Method Implementation
public void AppStore()
{
Console.WriteLine("AppStore Method: The Application Store of this smartphone is Google Play");
}
}
class Program
{
static void Main(string[] args) { }
}
}

So, this way we can get multiple inheritance in C#. Let's create the objects of the concrete classes Apple and Samsung and build the project.

using System;
namespace InterfaceDemo
{
interface ISmartPhone
{
void OS();
void AppStore();
}
//New Interface meant only for Apple Class
interface IFeatures
{
void TouchID();
}
class Apple: ISmartPhone, IFeatures
{
//OS Method Implementation
public void OS()
{
Console.WriteLine("OS Method: The OS of this smartphone is iOS8");
}
//AppStore Method Implementation
public void AppStore()
{
Console.WriteLine("AppStore Method: The Application Store of this smartphone is iTunes");
}
//TouchID Method Implementation
public void TouchID()
{
Console.WriteLine("TouchID Method: This method provides Touch/Gesture Control features.");
}
}
class Samsung : ISmartPhone
{
//OS Method Implementation
public void OS()
{
Console.WriteLine("OS Method: The OS of this smartphone is Android");
}
//AppStore Method Implementation
public void AppStore()
{
Console.WriteLine("AppStore Method: The Application Store of this smartphone is Google Play");
}
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine("//////////////////// - Interface Demo - //////////////////// \n");
Console.WriteLine("Apple SmartPhone:");
Apple apple = new Apple();
apple.OS();
apple.AppStore();
apple.TouchID();
Console.WriteLine("\n\n");
Console.WriteLine("Samsung SmartPhone:");
Samsung samsung = new Samsung();
samsung.OS();
samsung.AppStore();
Console.ReadKey(); }
}
}

If we run the code now, it works perfectly.

compile demo

This is the simplest example of using interfaces. However, this is just a real-world analogy and the approach can be debatable. My intent in this demo is to let beginners understand how to work with interfaces. The following are the key points to be remembered when working with interfaces.

Key Points of C# Interface

Interface Reference Variable

An interface has no implementation and cannot be instantiated. However, it can be referenced to the class object that implements it. It may be noted that the object can only access the inherited members of the interface. Consider the following code:
1. using System;
3. namespace InterfaceDemo
4. {
5. interface IDriveable
6. {
7. void Drive();
8. }
10. class Car : IDriveable
11. {
12. public void Drive()
13. {
14. Console.WriteLine("Car Class: I can drive a Car.");
15. }
16. }
18. class Truck : IDriveable
19. {
20. public void Drive()
21. {
22. Console.WriteLine("Truck Class: I can drive a Truck.");
23. }
24. }
26. class Program
27. {
28. static void Main(string[] args)
29. {
30. Console.WriteLine("//////////////////// - Interface Demo - //////////////////// \n");
31. IDriveable DriveCar = new Car();
32. IDriveable DriveTruck = new Truck();
34. DriveCar.Drive(); //Calls Car's Drive() method
35. DriveTruck.Drive(); //Calls Truck's Drive() method
36. Console.ReadKey();
37. }
38. }
39. }
The code shows the declaration of objects with the same interface Reference but with various functionalities.
Explicit Interface Implementation

When working with interfaces, there occurs a situation when a class implements two interfaces and both the interfaces contain a member with the same signature. When the class provides a definition to interface members, it gets confused about which member gets the definition since both have the same name. In that case, we'll an Explicit Interface Implementation.

Suppose we have two interfaces ICreditCard and IDebitCard and both of these interfaces have the same method signature called CardNumber and a class Customer implements both of these interfaces.
1. using System;
3. namespace InterfaceDemo
4. {
5. //First Interface IDebitCard
6. interface IDebitCard
7. {
8. void CardNumber();
9. }
11. //Second Interface ICreditCard
12. interface ICreditCard
13. {
14. void CardNumber();
15. }
17. //Customer Class implementing both the Interfaces
18. class Customer: IDebitCard, ICreditCard
19. {
20. }
22. class Program
23. {
24. static void Main(string[] args) { }
25. }
26. }
There are two ways to provide method definitions to interface members in a derived class. If you right-click on the interface name, Visual Studio gives you two options to implement them.

If we implement the interface normally and provide a definition to the CardNumber method, it will cause both interfaces to use CardNumber as their implementation. We cannot provide different functionality to the interface members.
1. using System;
3. namespace InterfaceDemo
4. {
5. //First Interface IDebitCard
6. interface IDebitCard
7. {
8. void CardNumber();
9. }
11. //Second Interface ICreditCard
12. interface ICreditCard
13. {
14. void CardNumber();
15. }
17. //Customer Class implements both the interfaces
18. class Customer: IDebitCard, ICreditCard
19. {
20. public void CardNumber()
21. {
22. Console.WriteLine("Card Number: My Card Number is 12345678901234567890");
23. }
24. }
26. class Program
27. {
28. static void Main(string[] args)
29. { }
30. }
If we compile the program now, the output creates more confusion since we are unable to decide which interface method was implemented since both of the interfaces share CardNumber as their method.

In this case, we need to tell the compiler which method is specific to which interface using Explicit Implementation. It can be done by prefixing the interface name with the method definitions in the derived class. It may be noted that explicit interface definitions are automatically public and hence no access modifier is allowed with the method definitions. We can still have the shared method definition in it.
1. using System;
3. namespace InterfaceDemo
4. {
5. //First Interface IDebitCard
6. interface IDebitCard
7. {
8. void CardNumber();
9. }
11. //Second Interface ICreditCard
12. interface ICreditCard
13. {
14. void CardNumber();
15. }
17. //Customer Class implements both the interfaces
18. class Customer: IDebitCard, ICreditCard
19. {
21. void IDebitCard.CardNumber()
22. {
23. Console.WriteLine("Debit Card Number: My Card Number is 12345XXXXX");
24. }
26. void ICreditCard.CardNumber()
27. {
28. Console.WriteLine("Credit Card Number: My Card Number is 98999XXXXX");
29. }
31. public void CardNumber()
32. {
33. Console.WriteLine("Customer ID Number: My ID Number is 54545XXXXX");
34. }
35. }
37. class Program
38. {
39. static void Main(string[] args)
40. {
41. Console.WriteLine("////////////////////- Implicit and Expliction Implementation -//////////////////// \n\n");
42. Customer customer = new Customer();
43. IDebitCard DebitCard = new Customer();
44. ICreditCard CreditCard = new Customer();
46. customer.CardNumber();
47. DebitCard.CardNumber();
48. CreditCard.CardNumber();
50. Console.ReadKey();
51. }
52. }
53. }
If we run the program now, we are able to differentiate members using an Explicit Interface.
If you have some kind of default functionality to share across classes in the hierarchy, you can use an abstract class. But if you don't have any default implementation and just need to define contracts for derived classes to follow; interface is the most preferred choice.
It is a standard rule when using an interface, be sure you have done it right the first time. Once the interface is implemented by derived classes, it is difficult to update or modify the interface since everyone else's code breaks.

Conclusion

I hope this article helps you to understand the various possibilities of interfaces. Your feedback and constructive criticism is always appreciated, keep it coming. Until then, try to put a ding in the Universe.

Abstract Class & Interface: Two Villains of Every Interview – Part 1

67 Comments

Join the conversation! Your thoughts help the community grow.

Kish7y ago
TouchID- In part 1 you mentioned we can define local methods in derived class. so we can add TouchID method only for Apple class. Then no need of interface here...
vijayakumar Jothi8y ago
TouchID - can be implemented as virtual method, and implement by override only in Apple class, leave as it is, in other classes like Samsung - then no need of interface here.
manoj singh8y ago
One interviewer asked me about Why c# does not support multiple inheritance Then i Explain the ambiguity thing happens in multiple inheritance. Then he say pure abstract class looks like interface then why we can not inherit more then one pure abstract class
- Bhuvanesh Mohankumar8y ago
  Pure abstract class, it looks like but not actually an Interface. The keywords like [Abstract/Interface] make the compiler to understand what type of object it is and how to handle it during compilation. It's just a machine level understanding and how the compiler is built.
Vijendra Kushwaha8y ago
Great article , thanks for sharing !!
Pardha Goud8y ago
Thanq very much Sir!
Abhinash Dora9y ago
Very well explained in both part 1 and part 2. It removes all my doubts about this. Now the two villains will become my friends. :)
Zeeshan Sattar9y ago
Hats off amazing explanation :) (Y)
Maddy N9y ago
First Of all article is well explained. I have a query. Suppose, In future, we need to introduce one more type of phone in which we have not the concept of AppStore(); then in this case what will you suggest?
Nghia Phan9y ago
It is very useful. Thanks you so much!
Madhuri V9y ago
Really your explanation is simply cleared my confusion.....Thanks alot Sahil:)
Mazhar Pasha9y ago
Awesome..Explained in detail..If anybody gone through these 2 articles then their confusion will go. Thanks for sharing..
vijay patel9y ago
Please reply on Harminder Singh comment.. i am also waiting for your response.
- Sahil Sharma9y ago
  Hi Harminder, Vijay - yes you can add local methods to a derived class and use it. The only use of methods mentioning in Interface is for common functionality.
Ravi Kumar10y ago
Good one, Sahil and and well explained.
mayank Gupta10y ago
I think this article should get the award for Best explanation about Interface & Abstraction. Even MSDN is far behind it. Extraordinary write. Thank You for your efforts ! .
- Sahil Sharma10y ago
  Thanks a lot for such kind words.
Soumalya Das10y ago
Best airtical i ever seen in the net
Satish10y ago
Ever best article , I have read so far.. thank you
Bhuvanesh Mohankumar10y ago
Very nice article :)
Sabyasachi Mishra10y ago
Good one and well explained.
Anil Kumar Murmu10y ago
good one
Ajeet Mishra10y ago
Really nice
Jaipal Reddy10y ago
Good article. .
Harminder Singh11y ago
good article and nice explanation. Sahil Can't we add a local touchid() method to the apple class and use it( in case we don't want interface).
Sahil Sharma11y ago
Thanks a lot guys for such lovely comments. I'm glad to know it helps you to understand the different aspects of Abstract Class and Interface.
Hemlata Kushwaha11y ago
Best article for me. Superb Explanation. I was searching the difference between Abstract and interface from Long time. Now finally i got it satisfied Answer from your Article. Nice!
David Smith11y ago
The best article of all time. Thank God someone finally explain the difference from the start to end. I completely understand. Do you have and example explaining the difference between delegates and events just as you did akbstract class vs interface.
Upendra Pratap Shahi11y ago
superb sir....very nice explaination
Anuj Jain11y ago
Presented each concepts very nicely. Great Job!
Sharad11y ago
nice blog with good example...
Anil Kumar11y ago
Thank you,Enjoyed Taste of abstract vs interface (Spoon feeding).Keep Move on...........
Sahil Sharma11y ago
Thank you all for such comments. I'm glad you like this article.
Kamal Sharma11y ago
This is one of best article on abstract VS interface, I have seen on blogs Great work
Vinod TG11y ago
Awesome.. Cleared many confusions :)
Atieq ur Rehman11y ago
you said in we can not make instance of an abstract class in part 1 and in part 2 you said that interface is a pure abstract class then why you make instance of IDebitCard and ICreditCard ??? in main ?? IDebitCard DebitCard = new Customer(); ICreditCard CreditCard = new Customer();
- Mathankumar R11y ago
  Here he is not creating an instance for the interface, he create an instance for class and with reference of that interface. Thats it.
Nitin11y ago
great work..very informative.
Ritesh Patel11y ago
Excellent tutorial.
- Sahil Sharma11y ago
  thanks
Ritesh Patel11y ago
Hello
Khargesh Rajput11y ago
thanks for sharing important content
- Sahil Sharma11y ago
  thanks
Casper Barchager11y ago
Very good and easy to understand. Good explanation of why to use an interface instead of an abstract class in this example.
- Sahil Sharma11y ago
  thanks
Rahul Singh12y ago
Nice
Deb Kumar Ghosal12y ago
In one of the Interview I was asked "It is possible for a class A to implement only two methods out of four methods of InterFace "IInterface"? and class B will implement rest two methods inside the class? Is it possible, or allowed?
- Sahil Sharma12y ago
  Hey deb, i think it is mandatory for a derived class to implement all method definitions of an interface. We cannot choose interface methods on our own for implementation; it is like a contract to be fulfilled properly.
JUKE BOX12y ago
but in ur article u define interface as a pure abstract class supporting multiple inheritance???
JUKE BOX12y ago
since we can use constructors in abstract class ..why cant we use it in interface?????
- Sahil Sharma12y ago
  JUKE BOX - because Interface is not a class and constructors are meant only for classes.
Udaya kumar12y ago
very super man.
Siva Rama Krishna Krapa12y ago
Great article..Keep going
Gursewak Singh12y ago
Nice Article.
priya Perumpilavil12y ago
thanks Sahil Sharma for the post. It is very simple and understandable..good job
- Sahil Sharma12y ago
  Thanks Priya for the comment. Glad you liked it :)
Sandeep Vemula12y ago
good explanation with example....
- Sahil Sharma12y ago
  Thanks
salman aly12y ago
Great Post , your way of explanation is simply awesum
- Sahil Sharma12y ago
  Thanks man :)
Rajeev Ranjan12y ago
Dear sahil :- your writing skill is superv, also your example makes a great impact on mind. Such a great example you took.
- Sahil Sharma12y ago
  Rajeev Ranjan - Thanks for your kind words. I'm glad the article helps you in some way :)
Jai Singh12y ago
Nice post
- Sahil Sharma12y ago
  Thanks :)
Manju lata Yadav12y ago
Sahil whenever u got time Edit :-Interface Reference Variabl in keypoint section.
- Dinesh Beniwal12y ago
  Done Manju.
- Sahil Sharma12y ago
  Dinesh Beniwal. Thanks for the updation.