C # Interfaces

To those are working in IT may be technical or not , in their life they will come across term interface,
and almost every one know what does it mean i.e definition syntax and how to and when to use. Most of the coding guys say it  "as classes do not support multiple inheritance and it will be possible in interfaces"  and we say they don't have implementation only definition and no declaration.


So lets learn after what we know,

Interfaces are considered as a contract consisting of properties and methods  and events, when a class implementing the interface it makes a commitment i.e fulfilling contract by implementing ALL(properties also) its interface members 

By default all  members are public , we cannot specify access modifiers to interface members 

An interface is similar to PURELY abstract class i.e class containing all abstract members (i.e no implementation)

Benefits of using interface is that code can be easily Maintainable

When your GetPeople implementation changes i.e if it returns List<Person> then again you need to change your implementation in 1st case as we get compilation error

but we did not have to change the interface implemented code, thats because Person[] and List<Person> both Implement IEnumerable

so when we are coding to the abstraction we don't care about the specific class coming back.All we do is its is a class that fulfills the contract , which makes our code more resistant .As every collection in .NET implements IEnumerable our repository may be stack, queue or whatever ...everything will work exactly without any change.. SO thats thing about programming to abstraction if the underlying implementation changes our code doesn't care 

We can also strongly type the collection like IEnumerable<Person>

So when we are programming to abstraction , we're adhering to a contract , but we don't care about implementation details i.e Get the functionality you need and not bothering about the specific type.

How:

we want code that is extensible that can respond quickly to new requirements , if we come up with a contract that the core application can use then we can plug in any number of different implementations that adhere to that contract 

Improving extensibility :

 For  example say you are getting data from repository using Service...

Generally we will use repository pattern in coding i.e BL repository (May be using Services, or CSV or SQL Connection).. this may vary so what we do is.. create an interface with what is required i.e functionalities so we create an interface with CRUD operations we want and then we use it in presentation layer .. so that ur UI doesn't care about actual implementation whether using services or csv or what ever no change in using that ()

i.e what ever the class obeying the interface contract can be used

Sample service repo :

Without using interfaces: we have to create objects for each type and use them ..redundant code ... so when we care  only about operations(features provided) and don't bother about underlying implementation it really helps in extending your code with out actually disturbing the usage/Consuming in your  presentation layer

** When an interface is implemented in a class , its access specifier should be public only otherwise it'll throw error

** IF you have Interface I1 with Method M1 and Interface I2 with M2 and when you inherit I2 in your class then you have to provide implementation for both M1 and M2.

Explicit Interface Implementation 

so why explicit implementation? 

If you have 2 interfaces to be implemented you can have it with single method also but why explicity defining / implementing them as shown above?

Because when two interfaces you have inherit have same method name but different return types then this explicit implementation is mandatory

for example when you inherit IEnumerable<T> then you can see as (internally IEnumerable<T> inherits IEnumerable) then you have to provide implementation for both GetEnumerator and GetEnumerator<T>

Explicit implementation of interface member should not have Access modifier  

Program to an abstraction rather than a concrete type i.e -->Program to an interface rather than a concrete class

Actual Usage:

So as we have seen above when we use interface we actually bother about the functionality provided and not the type which is serving .. so we have minimal change in presentation layer but we have to pass the type we want to connect and get data like in prev example either csv or sql or whatever

So we have to pass from UI which type you would like to and your factory class will instantiate that class and return that object (Interface )

1.So how can we make zero impact on UI , not even passing type

2.In the example what ever may be the type either from service / csv / sql we have to load all three assemblies as wen instantiate them in factory class

Suppose if we  get new type then we have to change UI and also add reference to our repo factory class project build it and then change the repo factory ...

We can avoid all above using Dynamic Loading

i.e no need to pass type from UI or load assemblies

1.We wont pass from UI we'll pick from configuration key of web config

2.We manually put the dll in bin folder of project to pick them which will actually happen when we add a reference (we can have a post build event for that or if you dont want to give new build you can directly place them in bin folder )

like wise for others also we can enable what ever configuration you want to use

To dynamically load the dlls or assemblies

So now no need to change any code level implementation nor give any new build...

Just Change the web.config with new app settings and place the dlls of your new implementation type in bin folder... bang!! ... done with ZERO code level impact or change

Conclusion: So, on a final note what we all to remember is interface is commitment and contract :-)