[Not CC] question about abstract classes

Hello everyone,

today I was wondering: what's the use of abstract classes? They seem pretty useless to me.

Example code in Java (this concept will probably apply to other languages too)

public abstract class MyAbstractClass {
    public abstract void abstractMethod();
}

public class MyClass extends MyAbstractClass {
    public void abstractMethod() {
        System.out.println("This is a class");
    }
}

(This example code was taken from the Dutch Wikipedia article about abstract classes.)

What I don't understand is why you wouldn't just define (is this the correct name for creating methods?) the methods that MyClass needs, inside MyClass itself. Or is there something I'm missing? And are there situations in which an abstract class is useful?

Sorry if I'm being stupid right now, I'm not a Java developer or OOP specialist, you know. Just interested.

It basically is an interface where you can add premade classes. You can for instance implement an interface and just add a few methods that you should add for a basic instance. Then if you want to create an actual object, you need to extend it and must implement the methods from the interface but those which are added by the abstract class, you don't have to implement. Here some code:

public interface ITest {
  public void handleObj();
  public Object getObject();
}

public abstract class Test implements ITest {
  public void handleObj() {
    Object o = this.getObject();
    if(o instanceof X) {
      System.out.println("it is instance of X");
    }
  }
}

public class X extends Test {
  public Object getObject(){
    return this; 
  }
}

Now X is an instance of both X and ITest. It is a very great tool for OOP, because this is an example how you could create base classes and simply add other classes which are similair to the base class.

I would say, Google it more, for instance stackoverflow is a great resource!

Abstracts and interfaces are fairly similar in several ways. Bottom line is, they both tell you what kind of actions an object is capable of. An interface is just a list of methods - any class that implements one, must implement every one of the methods in it.

An abstract class can't be instantiated. A class must be abstract to contain or define "abstract" methods, which are generally pretty similar to interface method definitions.

An abstract method is a method that is defined (return value, name, parameters) but not implemented.

In order to create a non-abstract subclass of an abstract class, all abstract methods must be implemented.

The clue here is that, if you have an instance of an "unknown" class, and you know that class is 1) a subtype of a class that defines a certain method (abstract or otherwise), or 2) implements an interface that defines a certain method (OR inherits from a class that implements that same interface) you know that your object also is capable of the same method. Confused yet? I'm actually confusing myself by writing this. >_>

Basically, the gist of this comes down to polymorphism, a central concept in OOP. You make an abstract method when you know that you'll need a method, but you can't define it in that particular class EVEN IF it belongs there.

I can recommend picking up a book or something that explains it a bit more comprehensively, a lot of the concepts are related to eachother in ways that make them difficult to understand without a solid introduction to all of them. You sort of need the whole picture.

I'll just point out abstract methods and interfaces are useful in situations where you might (perhaps) be writing a library and want other people to extend it and use it. Perhaps this library needs a callback that will be called when a button is pressed. In Java, you can't actually simply pass in a function to the library to be called when the button is pressed, like you can in Lua, or a bunch of other languages:

function onButtonPress()
  print("Do stuff")
end

myLibrary.addButton("hello", 3, 4)
myLibrary.setButtonCallback("hello", onButtonPress) -- passing the onButtonPress function as a parameter

In Java, what you have to do instead is define an interface, or a class with an abstract method, and then subclass the abstract class or implement the interface, then create an instance of that new class, then pass that instance into the library. This way the library can be sure that the passed in object contains the callback method, and can be sure the program won't crash if it tries to call that method.

-- As part of the library
package com.mylibrary.button;
public abstract class ButtonCallbackClass {
   abstract void onButtonPress();
}


-- As part of your code
public class MyButtonCallbackClass extends ButtonCallbackClass {
  void onButtonPress() {
	System.out.println("Do stuff");
  }
}

public class Main {
  public static void Main(String[] args) {
	MyButtonPressClass callback = new MyButtonPressClass();
	myLibrary.addButton("hello", 3, 4);
	myLibrary.setButtonCallback("hello", callback);
  }
}

You have to do this because Java is what's called a statically typed language (unlike Lua, and Javascript, and Python, which are dynamically typed), meaning that at compile time, Java must know the type of every variable (eg. String str = "hello";, instead of just str = "hello"), the return value of each function, the name and parameters of each function, etc… Unlike in Lua and Javascript, where you can just make that stuff up at runtime (while the program is running). Because of this, myLibrary must know for sure that the button callback object you pass in has the function onButtonPress implemented in it, it's just the design of Java.

You can do the same above Java code using interfaces as well, which are probably nicer than abstract classes IMO.

GravityScore, on 28 January 2014 - 04:14 AM said:

Snip

You just explained the interface :P/>
You would use an abstract class if you want to have a custom constructor or some premade code so you don't have to retype it each time. An abstract class is just a time saver.
Really, this probably is explained way better by somebody else, thenewboston for instance.

Engineer, on 28 January 2014 - 04:38 AM said:

Really, this probably is explained way better by somebody else, thenewboston for instance.

I think it was explained fairly well above myself… :)/>

i've never liked any of the new boston stuff - especially on programming - maybe it's because i just don't get the USA "Street" style they seem to be done in… but the presentation style just puts me off.

codeproject has a good summary though: http://www.codeproject.com/Articles/11155/Abstract-Class-versus-Interface
that page is specifically about C#, but the essence of it is identical.