Java abstract and interfaces

Yes it does.

Attached: 1497289143277.jpg (480x480, 18K)

A class is like a struct with functions.

With an abstract class you don't know yet how big the "struct" is so you can't make it.

That's how I see it.

Learn Smalltalk.

But that doesn't make sense to me.

If you want to write code, but don't yet know what to write, then just don't write it?

Why even bother adding abstract...

abstract class A
{
abstract int add(int a, int b);
}

abstract class B extends A
{

}

docs.oracle.com/javase/tutorial/java/IandI/abstract.html
docs.oracle.com/javase/tutorial/java/IandI/createinterface.html

Speaking C++-wise here.

They are used as base classes for other classes to inherit from.

When you inherit from the abstract class, you MUST override all the pure virtual functions. ( if you want the class to be non-abstract )

I don't really use them all that much, but I guess they would be good for pajeets who make a new class and when you try and call object->cleanup(); they have to have actually implemented it, otherwise it won't build.

because they are redundant and people's logic rebels against illogic

All of that shit is obvious if you understand inheritance.

so inheritance is hard.

Abstract class is just a prototype for a instantiated subclass. I.E. animal as an abstract class, there's no such thing as animal, but animal defines behaviours that the instantiated subclasses should have. I.e. eat, shit, walk, etc. each subclass i.e. cat, dog etc. would have their own unique implementation of these methods, and the abstract class enforces that by defining the abstract methods. instantiated subclasses cannot have abstract methods because you're actually going to instantiate that class so nothing should be abstract in it, an abstract class can have all real methods that as the sub class can inherit these and fall back on them if you decide to not define said method or constructor in the sub class.

An interface is just what it says, an interface, think of one of those toys kids play with where you push the correctly shaped blocks through the different size holes. The interface just holds both sides of a party to a common standard. So you design your method headers before you start actually building component X which means you know what you have to produce for each part in component X to match the interface, but also everyone else that is going to use component X knows how to call the functions on it.

That's pretty much it.

well,your brain is a little bit slow thats all.

wow this is actually a really good explanation

holy shit
this was 10x better than anything my professors had ever explained to me

>this was 10x better than anything my professors had ever explained to me

there really exists an OOP class that doesn't use the animal/cat or a fruit/apple analogy to explain inheritance?