Interfaces in Object Oriented Programming

[akizuki]

---

Share lang ko gamay sa interfaces. If we do research re interfaces like kana mga oop topics, books, etc, usa sa ato magrasp na application niya kay sa design jud. If implemented properly, one of the foundations cya sa good oop design. Malabyan nato ni cya during school.

However, in real world, there's more to it than just one of the good "rules" in ood. If nakafamiliar mo sa COM technology invented by Microsoft many years ago, so far, murag mao ni ang existing technology karon na ng "unleash" jud sa power sa interfaces, among others. COM is the foundation of many Microsoft technologies, including COM+, DCOM, OLE, ActiveX and .NET. Android pod, murag same idea sa COM but they call it Binder Interfaces.

Overview of COM application in simple terms:
Naa kintahay ko gihimo na new device nga mudetect ug gwapa ang nggamit or dli. Nya iconnect cya thru USB. Ngprovide nasad ko ug driver for the device. Usa ra ka function ang gamit sa device. Mudetect ra if gwapa ang nggamit. For me to easily sell my device to programmers, dapat magamit akong device sa common, if not tanang languages available karon. So normally, other than sa driver, magprovide pod ko ug library (usually written in C/C++) packaged as SDK. To achieve that, my library should be a COM-based library. Meaning naa koy gi-expose na "interface" for other languages to access my library. Why interface man? Why dili man header file lang? Kay interpreted languages (Visual Basic, VBScript, JavaScript, etc) cannot include header files. C/C++ lang ang malipay if header file lang ako iprovide. Thus, COM interface akong iprovide para malipay tanan. Using sa akong giprovide na C/C++ interface, other C/C++, .NET languages, VBScript, JavaScript, etc programmers can access or use my library directly in their code. Chada di ba? Instead of each programmer providing their own codes/functions to use the device.

Simple ra nuon na nga scenario but the idea is there. Windows itself is composed of thousands of libraries na nag expose ug COM based interfaces. Any programmer, regardless of what language you use, can use these libraries (and I mean very powerful libraries as far as functionalities are concerned) by using their provided interfaces.

[Tin_Tin]

Thanks sa inyong input, though rarely ra jud ko maka gamit ug interfaces when mag OOP but at least nahayagan na akong gikalibgan!

[yanong_banikanhon]

Share lang ko og gamay sa akong nasabtan bahin sa interface, ha.

Morag ang interface, contract na siya. Kana bitaw'ng mosulod tag trabaho, naa man contract nga atong pirmahan. Nakasulat sa contract ang mga butang nga angay natong buhaton samtang employee pa ta. Isip empleyado, kinahanglan gyud tang mosunod sa mga clause nga nakasulat sa contract. Kun dili ta mosunod, lagmit, matanggal ta sa trabaho.Dali ra ang pag-manage sa employer sa iyang mga tawo kay ang tanan nagsunod man sa usa ka contract.

Sa OOP context, kun ang usa ka 'class' mo-derive sa usa ka 'interface', obligado nang maong 'class' nga mo-implement sa mga method ni interface. Kung dili ma-implement ang mga method ni interface, dili mag-compile ang code. Kadtong mogamit sa mga classes nga nag-implement ni interface dili na maglibog kay kabalo man siya nga kaning maong mga 'classes' pareha ra og mga method ni interface (kay lagi ni-inherit man sila ni interface).

Example:

Adunay daghan mga klase sa sakyanan: naay kotse, pick-up, multicab, jeepney, etc...Obviously, lahi-lahi ang mga makina og mga pyesa aning mga sakyanana. Lahi-Lahi pud ang pagkahimo. Kun ang pagpaandar sa kotse pinaagi sa push-button, unya ang pick-up, birahon ang pisi duol sa makina (morag pump boat), ang sa multicab, huyopon ang tambutso....wala nay ganahan motuon og drive.

Mao na dunay common interface ang mga sakyanan: ang yabi ug yabihanan. Hapsay kaayong huna-hunaon nga inig kakita nato sa yabihanan (regardless kun unsay model sa imong sakyanan), sigurado gyud ta nga mao nay tuslokon aron moandar. Ing-ana pud ang interface sa OOP.

[canobic]

What is the advantages of using interfaces?
What's the difference between defining methods in your classes and with having interfaces, diba ma doble2x naka ug declare?

You'll appreciate the use of interface or 'programming against interfaces' when you're using IOC or Inversion of Control. But anyway, the main objective that you want to achieve by programming against interfaces is encapsulation, hiding, loose coupling, etc etc...

The point is that your software components should be loosely coupled as much as possible to make it flexible, portable, maintainable, and all the 'bles' out there.

What is the difference between:

MyTerrorist mt = new MyTerrorist();
mt.detonateBomb(); //will detonate bomb under Obama's desk 

compared to:

MyWarInterface mwi = new MyTerrorist();
mwi.detonateBomb(); //will detonate bomb under Obama's desk 

given that MyTerrorist implements MyWarInterface.

There's not much difference right? But what if I have another class MyPatriot that implements MyWarInterface and I want to use it as per requirement.

MyPatriot mp = new MyPatriot();
mp.detonateBomb(); //will detonate bomb under Bin Laden's bed 

compared to:

MyWarInterface mwi = new MyPatriot();
mwi.detonateBomb(); //will detonate bomb under Bin Laden's bed 

Do you see the difference? Still not that much right? But what if I want to use the Factory pattern so that my user class won't know who the implementing class is (MyTerrorist or MyPatriot):

MyWarInterface mwi = MyFactory.getCurrentWarClass();
mwi.detonateBomb(); 

Here I can have an external configuration file to switch from MyTerrorist to MyPatriot without changing any lines of code.

Now the user class has no idea whether MyPatriot or MyTerrorist is the implementing class. All it needs to care about is MyWarInterface and what it can do. What is the advantage? Again, loose coupling. The lesser your software components depend from each other the better they are because then their abstraction layer is enhanced and your components become more likely to be reusable.

Again the concept of programming against interfaces is more appreciated with using IOC. Because the Factory pattern still exposes the implementing classes in someway. And the thing about programming against interfaces is that it's a subtle concept to learn when you're working with simple business requirements. But with more complex requirements you'll come to see its advantages and why it's a must to program against interfaces.

[yanong_banikanhon]

Bay canobic, pwede nimo i-explain in layman's term ang kalainan sa Factory Pattern ug sa Inversion of Control (IoC)?

Para pud medyo 'digestibol' sa mga magtutuon ba. Lisud man sabton kun mo-diretso lang ta'g pang-labay og mga 'technical terms' without explaining their meaning. Just take into consideration nga nagpatabang man gani si TS bahin aning interface. Dili kaha mosamot ang iyang kalibog inig kabasa niya anang IoC ug Factory pattern? Just my two cents, though.

Unya naa pud koy gamay nga question sa imong example. Kung wala ka kabalo unsa ang actual nga implementation MyWarInterface, dili kaha dilikado nga gamiton ang detonateBomb() method? Given the fact that calling that method could either detonate a bomb under Obama's Desk or under Bin Laden's Bed? Pananglit i-edit sa usa ka malicious user ang configuration file to switch from MyPatriot to MyTerrorist, paskang patayang Obama.

I like the idea of programming against the interface but I think that particular example could do more harm than good.

[maddox22]

Unya naa pud koy gamay nga question sa imong example. Kung wala ka kabalo unsa ang actual nga implementation MyWarInterface, dili kaha dilikado nga gamiton ang detonateBomb() method? Given the fact that calling that method could either detonate a bomb under Obama's Desk or under Bin Laden's Bed? Pananglit i-edit sa usa ka malicious user ang configuration file to switch from MyPatriot to MyTerrorist, paskang patayang Obama.

I like the idea of programming against the interface but I think that particular example could do more harm than good.

Kataw-anan man ni...

@yanong_banikanhon, do you think not using configuration files makes your application any way safer?

'Loose coupling' pasabot ni @canobic diri minimizes dependencies. That's best practice! If dependent kaayo imo mga classes from each other then dili na reusable.

[maddox22]

http://en.wikipedia.org/wiki/Inversion_of_control

[canobic]

I don't think the question is laughable.

But yes as @maddox said it doesn't make your application any way safer. Once a hacker gets access to your server there's really so much he can do. Whether you internalize your wirings inside your code or whether you externalize it in xml config files really doesn't make any bit of difference at this point. A hacker can patch .class files easily as editing config files or edit .jsp and php files. He may even get database information and gain access to it. So it's a totally different world of concern and there are measures against it. Internalizing your wirings isn't one of them!

@yanong_banikanhon, as for your concern with loose coupling, if I understand you correctly, I think you see the state of a user class not knowing who the implementing class is as a 'negative thing'. No. It is not a negative thing but in fact a very good thing in software practice. Consider how difficult it would be to switch from one implementing class to another if you have 100 instances of tighly-coupled dependencies in your application! You'll have to go through all 100 instances and edit them. When your design is loosely coupled then you can just edit one line of code from your config file and the job is done! It won't matter if you have one instance or a thousand.

This example takes the situation in a very simplistic view, but I hope this helps.

[canobic]

@yanong_banikanhon, as to your question what a Factory pattern is and what IOC is, well... there are plenty of resources available in the web. A simple Google search will do the trick. But here's a simple example...

Consider the difference when using the Factory pattern:

public class MyUserClass {    
    public void detonateBomb() {
        MyWarInterface mwi = MyFactory.getCurrentWarClass();
        mwi.detonateBomb();
    }
} 

And this one with (IOC) Dependency Injection in Spring:

public class MyUserClass {
    private MyWarInterface mwi;
    public void detonateBomb() {
        mwi.detonateBomb();
    }
    public void setMwi(MyWarInterface mwi) {
        this.mwi = mwi;
    }    
} 

(Spring) Dependency Injection xml config file:

<bean id="myTerrorist" class="com.istorya.MyTerrorist"/>
<bean id="myPatriot" class="com.istorya.MyPatriot"/> 

You can use either implementing class with:

<bean id="myUserClass" class="com.istorya.MyUserClass">
    <property name="mwi" ref="myTerrorist"/>
</bean> 

or

<bean id="myUserClass" class="com.istorya.MyUserClass">
    <property name="mwi" ref="myPatriot"/>
</bean> 

Your MyUserClass has no idea who the implementing class is for MyWarInterface which means that switching implementing classes won't affect the MyUserClass.

If you want to add a third implementing class say 'MySpy' class that implements MyWarInteface, then just add another bean instance. You can then switch to this new implementing class that blows both Obama and Bin Laden to the moon!

<bean id="mySpy" class="com.istorya.MySpy"/>
<bean id="myUserClass" class="com.istorya.MyUserClass">
    <property name="mwi" ref="mySpy"/>
</bean> 

[yanong_banikanhon]

Kataw-anan man ni...

@yanong_banikanhon, do you think not using configuration files makes your application any way safer?

'Loose coupling' pasabot ni @canobic diri minimizes dependencies. That's best practice! If dependent kaayo imo mga classes from each other then dili na reusable.

Hehe...you totally missed the point, bro. Dili ko against anang loose coupling. I'm a big fan of the SOLID principle. It is just that the example given by canobic did not actually capture the real essence of the 'programming against the interface' principle. You might ask why.

It is because the two implementation classes: MyPatriot and MyTerrorist are actually not related. In fact, the purpose of their existence are opposites (MyPatriot is design to kill Bin Laden, MyTerrorist is design to kill Obama). There is no way a SINGLE application will ever use MyPatriot and replace it with MyTerrorist afterwards (gawas lang siguro kun duna gyu'y dautang tuyo ang developer nga nag-code ani). The purpose of using interface is to easily replace the current implementation class with another RELATED implementation in the future.

One simple example where 'programming against the interface' shines is logging. You can have an ILogger interface with one method called Log(). Then you have three logger implementation classes: FileLogger, DatabaseLogger & EventLogger. FileLogger implements the Log() method by writing the entry to a file. DatabaseLogger implements the Log() by storing the entry to a particular database, and so on. Take note that each implementation of the Log() method achieves the same thing (i.e, persist a particular log entry to a persistent storage). So you can easily swap implementation without doing any harm.

If you have an implementation class whose Log() method achieves the opposite (for example, delete a log entry from a database), you cannot safely call iLogger.Log(). You have to check first what kind of ILogger you currently have. As silly as it may sound, this is the same scenario as MyPatriot & MyTerrorist. You have two opposing operations and you managed to hide it using MyWarInterface. This makes the life of the consumer of your API a little bit more difficult.