As a first reply, let me elaborate a bit on what sparked my interest in this topic. Perhaps I can gather some useful feedback on that as well, within the context of a larger discussion. I'm working on different types of slitscanners, which share large parts of their code.

For that reason I've chosen to work with an abstract Slitscanner class which holds 15 concrete methods and 4 abstract methods. So far there are two subclasses which both define the abstract methods in their own way (and share all other methods). Since I first had two completely separate classes, rewriting the code to use a shared abstract class is a step forward. All of that is pretty neat. But now things start to get more complicated:

1. Both current slitscanner subclasses are non-realtime programs. However, I also have existing code for a realtime (preview) slitscanner, which shares some code, but not as much. I feel that, as I add this and other types, some will use less of the original abstract class. Should I make a smaller abstract class (core functionality) or add a second abstract class (realtime + non-realtime)?
2. Extending classes is great, however they result in this case in different slitscanner objects. Ideally I want one Slitscanner object that will allow selection of different types (instead of different subclasses). Like a switch with different cases, but then in an object-oriented manner. Then I would for example be able to switch to a different type, without creating a whole new object. How would I be able to do this? Is this where an interface could help me?

First, I must say that I am a professional programmer, doing Processing for fun, helping there because I enjoy sharing my knowledge, and because I also learn stuff here!

Second, since I come from the imperative programming world, I had similar questions to your when I learned OOP: some concepts seem abstract, far fetched, not obviously useful...

Then, looking at some projects, reading some books (I recommend Head First Java and Effective Java), lot of blogs, doing lot of maintenance myself, I am starting to see the bigger picture.

You might find here and there that the general, modern trend is to program against interfaces, not classes. Except perhaps in the domain of GUI (like Swing, GWT...) or similar (scenegraphs), deep class hierarchies are less used.

I made recently a small prototype for my job, and for the data model, I defined lot of interfaces, then, sometime, abstract classes implementing the common parts of these interfaces, then concrete classes from these abstract classes or directly from the interfaces. Someday, I will show the UML diagrams I have done for this task.

Why use interfaces? What is their usefulness?
They are a kind of contract: a class implementing an interface guarantees to have the functions defined by the interface, with same parameters and return values.
The interest is once you have defined an interface, you can create several similar classes, acting in similar ways, yet different in effect. You can easily substitute one class with the other.
Thus the advice to program against interfaces: you define a variable with the interface as type, and can assign any objects implementing the interface. For example:
List list = new ArrayList(); // You can change to a LinkedList() if you need

I started a Processing project:
http://bazaar.launchpad.net/~philho/+junk/Processing/files/head:/MazeGeneration/
It isn't finished, but you can see I made interfaces for the carve algorithm, the cell displayer, and the wall displayer. This allows to use one of the other implementations of these interfaces, seamlessly.
The main code is:

1. GraphicalMaze maze;
2. CarveAlgorithm carver; // Interface
3.  
4. void setup()
5. {
6.   size(1100, 800);
7.  
8.   maze = new GraphicalMaze(MAZE_WIDTH, MAZE_HEIGHT);
9.   maze.setCellSize(CELL_SIZE);
10.   maze.setWallThickness(WALL_WIDTH);
11.   // Inject in the maze the classes I want to use
12.   if (bDebug)
13.   {
14.     maze.setCellDisplayer(new ColoredCellDrawer(this, maze));
15.     maze.setWallDisplayer(new ColoredWallDrawer(this, maze));
16.   }
17.   else
18.   {
19.     maze.setCellDisplayer(new EmptyCellDrawer(this, maze));
20.     maze.setWallDisplayer(new SimpleWallDrawer(this, maze));
21.   }
22.   // Concrete instance
23.   carver = new AlgoRecursiveBacktracker(maze.getMaze());
24. }
25.  
26. void draw()
27. {
28.   background(255);
29.   maze.display();
30.   if (!carver.isFinished())
31.   {
32.     carver.carveMaze();
33.     if (carver.isFinished())
34.     {
35.       println("Done!");
36.       maze.getMaze().carveEntries();
37.     }
38.   }
39. }

I used also a limited version of dependency injection, another concept that is trendy: you don't do new Stuff() in the class, but rather inject the object via the constructor (or a setter), allowing substitution of implementations and easy testing (via mocking, using fake implementations, easy to build and without side effects, like charging a credit card!).

Another note: a limitation of (abstract) classes is that you can inherit only one, while you can implement several interfaces. And it must make sense, with the concept of "is-a" (a dog is an animal), avoiding artificial inheritances (a window isn't a mouse listener, or not only). Thus is is recommended of avoiding inheritance (unless it really makes sense) in favor of composition ("has-a"): a window can have a mouse listener (an internal class). The class has variables providing the services it needs (logging, saving, etc.) instead of trying to artificially shoehorn the features in the class. The syntax is a bit more verbose, but it pays at the end.

There is lot more to say, but it looks like being already a big chunk to digest...

Extending classes is great, however they result in this case in different slitscanner objects. Ideally I want one Slitscanner object that will allow selection of different types (instead of different subclasses). Like a switch with different cases,

One solution to this problem is to use polymorphism . Polymorphism is an OO programming concept that works with an inheritance tree.

What follows is a quicky guide to using inheritance and polymorphism in your problem domain - slitscanners. The diagram shows a simple inheritance tree with an abstract base class and 3 child classes.


Notice that all the classes have a method called getScan and they all have no parameters and the same return type (float).

To use polymorphism it is essential that the methods have the same signature i.e. same parameter order, and return type. The method should also be declared protected or public.

So now we want an application that can be used with any of the 3 child classes.

Lets assume we have another class that requires a slit scanner object but it could be any of the 3 available. To do that we declare an attribute of the abstract class type e.g.

protected BaseSlitScanner scanner;

This can be used to create a scanner object from any of the child classes so any one  of these would be acceptable.

scanner = new RTimeSlitScanner();
scanner = new SlitScannerTypeA();
scanner = new SlitScannerTypeB();

We can use our scanner with
scanner.getScan();

It will execute the getScan method in the correct class. This is called method overriding and is demonstrated with this simple sketch

1. A x, y, z;
2. 
   
3. void setup(){
4.   x = new A();
5.   y = new B();
6.   z = new C();
7.   x.whoAmI();
8.   y.whoAmI();
9.   z.whoAmI();
10. }
11. 
    
12. class A {
13.   void whoAmI(){
14.     println("You are in class A");
15.   }
16. }
17. class B extends A {
18.   void whoAmI(){
19.     println("You are in class B");
20.   }
21. }
22. 
    
23. class C extends A {
24.   void whoAmI(){
25.     println("You are in class C");
26.   }
27. }

The output from this is
You are in class A
You are in class B
You are in class C

OO is more than just about organising code, it is also about software design.

BTW Inheritence is a concept - so there is only one type of inheritance

This is very helpful guys, thanks! Your abstract concepts are currently having a ping-pong match in my head, which exploded somewhere between "yes, this makes perfect sense" and "I don't get it". But I will re-read and just take my Slitscanner code as a testing ground for these concepts.

@ phi.lho: I have found the two books you suggested online and have them on my e-reader now. The Link hierarchy and your Maze sketch added to my understanding of the interface concept. Especially your use of setCellDisplayer seems very relevant to my situation. Dependency injection sounds like a concept that is very addictive once you start using it and it may in fact be what I was looking for, see below.

@ quarks: I need to understand these concepts better, probably take a very hard look at my code and maybe rearrange it. Having said that, your diagram is exactly what my current sketch looks like. And what I meant with the remark you quoted is when you do this...

scanner = new RTimeSlitScanner();
scanner = new SlitScannerTypeA();
scanner = new SlitScannerTypeB();

...you create an instance of either of these types of slitscanners. Once you have one, you can't switch to the other without creating another instance of a different type of slitscanner. Instead I was hoping to change the code, so I could do something like this...

scanner = new SlitScanner();

...but then later be able to do something like this...

void setScanner(TypeA);
float getScan(); // gets TypeA

...or...

void setScanner(TypeB);
float getScan(); // gets TypeB

...where TypeA, TypeB and others are external to the Slitscanner class. Perhaps I should use polymorphism at the level of the scanMethod (A, B, RT) instead of at the level of the whole Slitscanner?

To conclude for now, this is something that will take some time to land. So I will keep at it!

I like the phi.lho's answer a lot. I would stress two more things and add one more to this very first steps in OOP. On the margin: I'm a self taught programmer working now (after a few years) as a full time software developer that had these questions some time ago as well.

First thing to stress: The interface is a type. That means that you can cast some object to interface and for example use it in the function call. See this classes implementing this interface:

1. public interface Testable {
2.       public void testMe();
3. }
4. 
   
5. class Sth implements Testable {
6.       public void testMe() {
7.             println( "testMe at work in Sth!");
8.       }
9.       // some class specific stuff
10. }
11. 
    
12. class Else implements Testable {
13.       public void  testMe() {
14.             println( "testMe at work in Else!" );
15.       }
16.       // some class specific stuff
    
17. }

1. void testApp( Testable t ) {
2.       t.testMe();
3. }

All right, thanks for your additions. I have found the Head First - Design Patterns book as well. It's from the same Head First series as phi.lho's suggestion. My collection of 'light reading' materials is really coming together nicely!

The Head First collection is excellent: they use a light tone (with humor), offers lot of exercises, and actually explore in deep the topics they treat. I have also read Head First SQL (and the start of the Design Patterns one) and found it very good too.

Like phi.lho I also started with procedural programming and experienced the same problems and had the same questions as you and everyone else when making the move to OO.

The big question is, whether to use inheritance with an abstract base class, or independant classes that implement an interface. There are advantages and disadvantages to both so the choice is yours and will depend on your knowledge of the specific problem domain.

If you look at the Java source code you will see both inheritance and interfaces being used. For instance the ArrayList inherits from AbstractList and also implements the interfaces List, RandomAccess, Cloneable and Serializable.

I should point out that there is no absolute rule which to use, in both cases you have specific scanner types that are ' a kind of' scanner that perform the same operations so have the same methods where the method implementation will be different for each scanner type.

An interface has no source code and can be thought of as a contract in that any class that implements the interface must provide implementations of the methods specified in the interface. An abstract class can have fully implemented methods as well as abstract methods so is useful if all your child classes need have a lot of common functionality.

Whether you use abstract classes or interfaces, each scanner type will be a different class. I have modified the code I previously posted (see below) to show how you can set the scanner before using it.

1. A x, y, z;
2. A scanner;
3. 
   
4. void setup(){
5.   x = new A();
6.   y = new B();
7.   z = new C();
8.   setScanner(x);
9.   scanner.whoAmI();
10.   setScanner(y);
11.   scanner.whoAmI();
12.   setScanner(z);
13.   scanner.whoAmI();
14. }
15. 
    
16. void setScanner(A s){
17.   scanner = s;
18. }
19. 
    
20. class A {
21.   void whoAmI(){
22.     println("You are in class A");
23.   }
24. }
25. 
    
26. class B extends A {
27.   void whoAmI(){
28.     println("You are in class B");
29.   }
30. }
31. 
    
32. class C extends A {
33.   void whoAmI(){
34.     println("You are in class C");
35.   }
36. }