OOP question: Can someone fucking explain to me what does it mean to hide complex implementation behind an interface?

Also whats the point of using interfaces when you can define methods in an abstract class and just override them in subclasses in order to get class specific implementations?

Not sure where you got the 'hide complex implementation behind an interface'

In C# an interface has only methods without code.

It tells a class what functions you can use, and then you implement the actual logic in that class.

An abstract class can have full logic.

It is also faster than an interface.

See more : https://educba.com/c-sharp-interfac...

Think of interface as of WSDL. It's a contract between a service provider and consumers. Interface defines

- WHAT can the service DO (methods)

- WHAT entities (DTOs/datamodels) is the service USING (data classes)

that's all. That's all it is. That's all it needs.

If you're going for an abstract class, you introduce dependencies on some artefacts. However, these artefacts might be utterly useless for the implementation you are actually using.. Effectively, you bloat your runtime.

For instance, if you have an abstract class that makes HTTP calls, you need OKHttp or Jetty or whatever HTTP client you're using. If you override its methods to load data from the filesystem instead - you will still need those HTTP libraries to compile your code.. even though you don't need them at runtime.

Referring to JVM, some features of JVM languages only support interfaces. They don't work with (abstract) classes. Like Proxy.

Abstract base classes are a great thing in this context, but only when used right. For contract - use ONLY interfaces. For interface implementations, if you want, you can extend a common MyServiceBase abstract class, that implements MyService interface. That way you still have a lean and minimalistic contract (which is great - it must be lean and minimalistic) AND you don't have to repeat yourself creating different implementations for it.

I want to mention the limitation that in most languages each class can only extend 1 other class (e.g. an absteact one) but use many interfaces.
Also keep in mind that not every language supports classes and inherance. Have a look at golang where a lot of stuff is done via interfaces.

You make a hard design decision that may change in future. You hide that decision behind an interface, so if it does change coz you made wrong decision, easier to change in future.

Also, abstract classes are interfaces, they're just language specific concept terminology.

@netikras now if only WSDL wasn't so completely and utterly borked up...

the idea is good, but the implementation would make cthulhu shudder..

i spent about 20 minutes trying to explain what is the usage for each, and how to decide what to use when...

...and then I decided to just post this video that I re-watched yesterday, and i think might have a point, as this question and my attempt to answer kind of demonstrated.

https://youtube.com/watch/...

@Midnight-shcode doesn't really answer the question, does it?

Question was: why use an interface when I can use an abstract class?

Your video's answer is: OOP is shit

BTW I've watched it and while it does have a few good points, the bashing on OOP is way off. OOP is not perfect, especially when misused or used with anarchy reigning in the pot positioned on dev's shoulders, but his proposals are arguable at the least. Inline functions bloating fn body beyond the event horizon? really...?

@netikras correct, it doesn't answer the question because i realized i have difficulties answering the question, because it's highly philosophical for me.

but, what i can get to is something like: inzerface is description of what a thing can do. a thing can do many things.

class is a description of what a thing is. a thing is only one thing, even though one thing can do many things.

abstract class is description of what a thing is... roughly. a thing can be only one thing, but have many flavots of how and why it is that thing.

basically, what i'm finding is, that interfaces are best used as traits - a thing can recieve and respond to clicks - interface that denotes that. a thing can x: interface that denotes and enables that.

class is a collection of several "can do" which aggregate into a "is a".
abstract class then "is some kind of a".

still, this is very vague and philosophical, and the more i try make sense of programming, the more i dislike when i have to do philosophy

@netikras it's one video in about 4video series, one of which is a practical example (the nes emulator), i recommend watching the others too, he expands on how and why of the alternatives.

@Midnight-shcode My view is, interface = a list of things that a class must have and use.

Interfaces provide specifications that a class must follow.

It does not hide complex functions or logic. Because all that logic will still be inside different classes (even with the same interface)

Abstract class is to have tools you can use for similar classes.

Here you can hide logic. Since all classes using that one abstract class will use the same logic.

I think whoever gave you this information is either wrong or expressing themselves poorly. Interfaces hide nothing. Certainly they have no implementation at all, by definition.

Oh and I believe the advantage of an interface is just that: you actually don't need to implement it. This works well in more complicated OOP scenarios like dependency injection where an implementation would be useless.

Classes that maintain their ABI can look like they are hiding things. When in fact they are maintaining their ABI.

Interfaces are for when the caller doesn't care about implementation. Abstract classes are partial implementation. They're for totally different things.

Say you press the "Buy" button on a web page. Your UI layer is provided an implementation of a class via DI and the interface it implements requires a method buyProducts that takes a list of products the UI provides from the "cart". The UI can only see the interface. It doesn't care what happens when it calls buyProducts, nor should it, just that whatever needs to happen happens, and when it's done, the UI can move to the "order placed" page.

@Grumm
you're not "hiding" anything, though. you're passing it down/avoiding repeating yourself. but i don't see how anything is hidden either in interface, or in parent class case. you could argue that interfaces "hide the implementation", as in, it's hidden behind the interface for whatever is calling functionality via that interface... but... again, i... rarely like doing this kind of philosophising because i quickly get lost in/confused by my own thoughts =D