Interfaces in Object Oriented Programming

[maddox22]

---

The fighting continues...

The previous example about MyPatriot and MyTerrorist both implementing MyWarInterface is not wrong. They both share a common functionality which is to denotate the bomb. They don't need to have a similar objective per se. One can denotate the bomb in a room, one can denotate the bomb in the garden, another one in the garage. Who cares? Those classes detonate a bomb thus they should implement MyWarInterface.

Similar to the example above walk(). One class can walk south, one can walk north, another can walk west, and another towards east. They all share the same functionality walk.

Don't confuse interface with an abstract class. If what your intention is that a dog, insect, monkey, chicken inherit a function walk() which means moving the legs one step after another, then you should use an abstract class or parent class say Animal. Then dog, insect, monkey, and chicken can inherit walk().

If your intention is to have DIFFERENT implementations like walk north, walk south, east, or west, then you should be using an interface. They don't need to have a 'common theme' as what @yanong is indicating. He's probably confusing it with an abstract class that's why he keeps on using the word 'operation' so much. Implementation and operation are two different things. What is important is that the signatures of your interface are implemented thus adhering to the contract.

In real-world practice, let's say your company is in the process of migrating from old systems so you have to build an application that will need to pull data from both a legacy database and from some web services published by some other systems... This is a typical scenario where data is scattered throughout multiple systems. Probably scalability was not anticipated.

Anyway, so you'll have a Repository interface with for e.g. a function findByAddress(String address). Then you'll have two implementing classes CustomerWS and CustomerDAO. The former retrieves customers from a web service by address, and the latter from a database or mutliple databases through stored procedures by address. They both have different implementations but still complying to the contract.

You can also have another set of implementing class like SupplierWS and SupplierDAO and both implementing findByAddress(String address). Their objective is to retrieve suppliers information from both web services and legacy databases by address.

So going back to the MyPatriot and MyTerrorist example we can translate that into a fictional application that manages World War III. You have the MyWarInterface with several functionalities or signatures and one of them is detonateBomb(). You then have several implementing classes MyPatriot, MyTerrorist, and MySpy all implementing the detonateBomb() signature since they are empowered to detonate bombs. One detonate bombs in the Whitehouse, the other in Bin Laden's palace, and the other, since he is a double agent, can detonate bombs in both places.

Do they share the same 'theme' of world peace or goody-goody-two-shoes? No.

Do they share the same ability to detonate bombs? Yes.

So should we use interface or abstract class? Interface! yey!

[yanong_banikanhon]

The fighting continues...

I really don't know why you keep on insisting the word 'fighting'. We are just having an exchange of ideas here. Don't take it personally. Kun nasayop ka sa imong pagsulti nga ang Spring DI framework maoy nagcontrol sa code execution, accept it as a fact. That's how a real programmer should react. Use logic, not emotion. Luod paminawon ng programmer nga emotional.

Anyway, lets get back to the discussion. I have a question which I hope you will answer professionally without resorting to name calling.

Mahimo ba nimong ipasabot unsa ang kalainan sa abstract class nga dunay abstract walk() method ug sa usa ka interface nga dunay walk() method?

[bearish]

Ang problema ra gyod ni yanong kay kato ra gyod detonateBomb() method nga lahi2x ug target. To kill obama and to kill bin laden.

the function of the method is the same --- to detonate the bomb but the target maybe different. very simple, just add an argument to the detonateBomb() method, like detonateBomb(arg_target) ....

para ang user will explicity specify his/her target.

pwede na siguro ni.

[maddox22]

I really don't know why you keep on insisting the word 'fighting'. We are just having an exchange of ideas here. Don't take it personally. Kun nasayop ka sa imong pagsulti nga ang Spring DI framework maoy nagcontrol sa code execution, accept it as a fact. That's how a real programmer should react. Use logic, not emotion. Luod paminawon ng programmer nga emotional.

Anyway, lets get back to the discussion. I have a question which I hope you will answer professionally without resorting to name calling.

Mahimo ba nimong ipasabot unsa ang kalainan sa abstract class nga dunay abstract walk() method ug sa usa ka interface nga dunay walk() method?

@yanong that was only an expression. haven't you heard of that expression being used before? It was actually meant to be funny... well at least not for you. Anyway, I'm sorry if you didn't find it funny.

So to answer your question, no. 1 an interface cannot have an implementation of its own unlike an abstract class can have a default implementation for walk() which can be inherited by subclasses.

no. 2 interface walk() is intended to be a signature or contract, if you like, so any implementing class can have its own implementation of walk(). while abstract class walk() is meant to be inherited and overriden. The subclass have the option to inherit or override walk() from the parent class.

Did this answer your question?

[jonasbelita]

karon @maddox ako na sad mangutana nimo. unsa may kalahian kung ang walk() sa imo abstract class nga ang default implementation kay walking-walking lang din gi-override sa usa ka subclass ug gi-usab ang implementation nga mag walking south na hinuon? unsa may kalahian ani sa imo example nga interface nga ang usa ka class walking north ug ang usa walking south? diba pariha ra ang resulta?

kung makaya ra diay sa abstract class din ngano maggamit pa man ug interface?

[maddox22]

This is a good question bro @jonas.

Yes it achieves the same goal with regards to the implementations. However it is not to say that one is better than the other. It's an argument that has been going on for a long time. It depends on so many situations whether to extend or to implement.

But here are a few keypoints to take note:
1. The difference between what something is and what something can do.
2. Decoupling major components. Use interface here.
3. Inheriting the attributes from the parent class - is it required or not? If yes then use abstract class.
4. Generic implementation. Use abstract class here.
5. Common sense. Your requirements will oftentimes dictate which one to use.

[yanong_banikanhon]

This is a good question bro @jonas.

Yes it achieves the same goal with regards to the implementations. However it is not to say that one is better than the other. It's an argument that has been going on for a long time. It depends on so many situations whether to extend or to implement.

But here are a few keypoints to take note:
1. The difference between what something is and what something can do.
2. Decoupling major components. Use interface here.
3. Inheriting the attributes from the parent class - is it required or not? If yes then use abstract class.
4. Generic implementation. Use abstract class here.
5. Common sense. Your requirements will oftentimes dictate which one to use.

Good answer, bay. Ingon ani unta. Healthy discussion ba.

[Klave]

karon @maddox ako na sad mangutana nimo. unsa may kalahian kung ang walk() sa imo abstract class nga ang default implementation kay walking-walking lang din gi-override sa usa ka subclass ug gi-usab ang implementation nga mag walking south na hinuon? unsa may kalahian ani sa imo example nga interface nga ang usa ka class walking north ug ang usa walking south? diba pariha ra ang resulta?

kung makaya ra diay sa abstract class din ngano maggamit pa man ug interface?

Add lang ko input gamay.

An interface usually serves to be a guideline for usage with a certain process.
An abstract class usually provides a default implementation. It may serve as a guideline for usage but is not necessarily the usage that matters.

Service Providers will opt to use an interface because they want code for the service untouchable and outside the bounds of the user. Using an abstract class would let me think that some parts of the service would be implemented inside the class which will be available for the sub-classes. I would like to think that Interfaces serves a purpose in design rather than just simply usage. It is clear that an Abstract Class would provide more functionality but it is a specific class and lacks the ambiguity an Interface can provide.

[silent-kill]

karon @maddox ako na sad mangutana nimo. unsa may kalahian kung ang walk() sa imo abstract class nga ang default implementation kay walking-walking lang din gi-override sa usa ka subclass ug gi-usab ang implementation nga mag walking south na hinuon? unsa may kalahian ani sa imo example nga interface nga ang usa ka class walking north ug ang usa walking south? diba pariha ra ang resulta?

kung makaya ra diay sa abstract class din ngano maggamit pa man ug interface?

hi jonasbelita, to answer this question, it is not safe to use the abstract class and not the interface. since you cannot assume that all implementation of Walk() only have 1 abstract source.

like in my example i have an Animal, Mechanical source. even if you have 1 common "abstract concept" lets call it WalkableAbstract, it does not guarantee that all Walk() method comes from the WalkableAbstract, since there is no restriction as long as you implement an interface.

[legal_cd]

class are mostly for data manipulation and common functions/procs

interfaces are direct and distinct way of interacting to the user thru UI and thru back-end data.

so there's no way na mag ka pareha or ma doble og declare, not unless, you are not structuring it correctly.