learningcsharp

what is the use of interface

what is the necessity of declaring first the signature of functions.



Re: Visual C# General interface

OmegaMan

An interface comes into play when you want to create a contract of operations. A consumer does not care about an object, just that the object that he/she is getting will do the work.

For example say you have a database layer and it attaches to the db and extracts values. The business layer process that data and sends it to the user/Gui. What if the database is going to change, say its a financial database and the company providing the info is going out of business. That requires a new vendor and its new database.

The user still needs data for reports and the new database will fulfill that. If the business layer is communicating with the database layer with interfaces and not objects, a programmer can write a new database extraction and return the data as per the spec of the interface. The developer can choose to reuse the original classes or write a new one...just as long as the contract is implemented in the interface. The other levels biz/gui don't change! There is the benefit.

The interface removes the need to be tied to a specific object or to return a specific object. One sees this in a factory pattern. One layer calls the factory and gets the interface. The factory can return any object as long as it conforms to the interface. The user can still cast it to the original object if it is known...but the interface allows a generic/common way of transferring objects that does not have to rely on all objects deriving from the same base.





Re: Visual C# General interface

learningcsharp

hi OmegaMan thanks for the reply.

what do u mean by this.

'If the business layer is communicating with the database layer with interfaces and not objects',

not objects means what





Re: Visual C# General interface

OmegaMan

When I say objects, I mean the specific classes that do the work. So the biz layer will new up the GetDataFromDB object and deal with its nuances to get the data. If it was an interface, the biz would call a factory and the factory would new up the same object, but return its interface, saying something like this:

Code Snippet

ImyWorkerDB worker = Factory.GetDBWorkers("GeneralLedger");


That is how the biz layer gets the general ledger class as an interface iMyWorkerDB which then can be acted upon. If the biz layer knows its a GeneralLedger object it can cast it such as

Code Snippet

GeneralLedger myGL = worker as GeneralLedger;

if (myGL != null) // Test to check if the cast was valid.
{ ... }
else
{ throw new Exception("Something is wrong with GL cast"); }


Note most often the layers that use interfaces will not cast on the other side, it kind of defeats the purpose of having the interface in the first place. Because as mentioned if the database layer changes and the object is no longer valid, it will break consumers who were using the factory and casting to the old instead of just working with the interface. Hope this helps.




Re: Visual C# General interface

odujosh

It provides an abstraction so you can hide implemenetation.

If you using a third party tool or lib than you could standardize naming even if their naming wasn't standard. You could pull the dependencies by just reimplementing the interface with code or another liabary without rewriting the coupling (the calls to the methods in the lib)

Alot of people call it programming by contract. Which exposes a second use. You don't care what Object X is all you want to be able to do is dispose it. Well you would just implement IDisposable (a very important .NET interface) and you would be able to do this.

void TrashIt(IDisposable toDispose)

{

toDispose.Dispose();

}

In this way the only access you have to object toDispose is what the IDisposable interface exposes. Which is just the void Dispose() method.

You don't care how Dispose is implemented. You just care they implement it.