"Hiding" members with Explicit Implementation
Don't you hate it when interfaces pollute you class with too many members you don't even care about? Well I got a solution! Explicit Implementations
Normally you'd implement the class like this.
Every member is public.
Answer: I don't. So neither should it be declared public but simply declaring the members as private will make the compiler throw an error
The solution is to use explicit implementation:
So now you have implemented the members as required and they wont expose any members in as public.
If you seriously still want to access the member even though is explicitly implement all you have to do is cast the object to the interface and you good to go.
Explicit interface implementation
Explicit interface implementation is necessary when you implement multiple interfaces who define a common method, but different implementations are required depending on which interface is being used to call the method (note that you don't need explicit implementations if multiple interfaces share the same method and a common implementation is possible).
The implementation cannot be called from anywhere else except by using the interface:
Due to this, it may be advantageous to put complex implementation code of an explicitly implemented interface in a separate, private method.
An explicit interface implementation can of course only be used for methods that actually exist for that interface:
Similarly, using an explicit interface implementation without declaring that interface on the class causes an error, too.
Implementing interfaces explicitly can also be used to avoid dead code. When a method is no longer needed and gets removed from the interface, the compiler will complain about each still existing implementation.
Programmers expect the contract to be the same regardless of the context of the type and explicit implementation should not expose different behavior when called.
So unlike the example above,
Drive should do the same thing when possible.
as an Example of Implementing an Interface
Interfaces can seem abstract until you seem them in practice. The
IComparable<T> are great examples of why interfaces can be helpful to us.
Let's say that in a program for a online store, we have a variety of items you can buy. Each item has a name, an ID number, and a price.
We have our
Items stored inside of a
List<Item>, and in our program somewhere, we want to sort our list by ID number from smallest to largest. Instead of writing our own sorting algorithm, we can instead use the
Sort() method that
List<T> already has. However, as our
Item class is right now, there is no way for the
List<T> to understand what order to sort the list. Here is where the
IComparable interface comes in.
To correctly implement the
CompareTo should return a positive number if the parameter is "less than" the current one, zero if they are equal, and a negative number if the parameter is "greater than".
Here's the example
Item's implementation of the interface:
On a surface level, the
CompareTo method in our item simply returns the difference in their ID numbers, but what does the above do in practice?
Now, when we call
Sort() on a
List<Item> object, the
List will automatically call the
CompareTo method when it needs to determine what order to put objects in. Furthermore, besides
List<T>, any other objects that need the ability to compare two objects will work with the
Item because we have defined the ability for two different
Items to be compared with one another.
Implementing an interface
An interface is used to enforce the presence of a method in any class that 'implements' it. The interface is defined with the keyword
interface and a class can 'implement' it by adding
: InterfaceName after the class name. A class can implement multiple interfaces by separating each interface with a comma.
: InterfaceName, ISecondInterface
Because they implement
dog are required to include the
string MakeNoise() method and will fail to compile without it.
Implementing multiple interfaces
An Interface's function known as a "contract" of functionality. It means that it declares properties and methods but it doesn't implement them.
So unlike classes Interfaces:
- Can't be instantiated
- Can't have any functionality
- Can only contain methods * (Properties and Events are methods internally)
- Inheriting an interface is called "Implementing"
- You can inherit from 1 class, but you can "Implement" multiple Interfaces
Things to notice:
- The "I" prefix is a naming convention used for interfaces.
- The function body is replaced with a semicolon ";".
- Properties are also allowed because internally they are also methods
This is especially useful when you're working with UI frameworks such as WinForms or WPF because it's mandatory to inherit from a base class to create user control and you loose the ability to create abstraction over different control types. An example? Coming up:
The problem proposed is that both contain some concept of "Text" but the property names differ. And you can't create create a abstract base class because they have a mandatory inheritance to 2 different classes. An interface can alleviate that
Now MyButton and MyTextBlock is interchangeable.
Why we use interfaces
An interface is a definition of a contract between the user of the interface and the class that implement it. One way to think of an interface is as a declaration that an object can perform certain functions.
Let's say that we define an interface
IShape to represent different type of shapes, we expect a shape to have an area, so we will define a method to force the interface implementations to return their area :
Let's that we have the following two shapes : a
Rectangle and a
Each one of them have its own definition of its area, but both of them are shapes. So it's only logical to see them as
IShape in our program :