Object Oriented Programming for All

Bis jetzt kennen Sie die compilerinternen Typen long und String, wobei String nur eine Vereinfachung der Sprache darstellt.
Mit der Einführung von Typenprüfung beim Methodenaufruf ist der Weg freigemacht für Methodenüberladung. Als gültige Typen gelten alle einfachen Klassennamen also z.B. String,zahl,StringArray usw. Daraus ergibt sich zwar ein Problem der Eindeutigkeit , wenn in verschiedenen Packeten Klassen gleiche Namen haben, aber das liese sich nur mit Performanceeinbußen vermeiden, in dem immer der Packetname statt des Klassennamens geprüft wird. Zudem würden zwei Amiga Libraries mit dem gleichen Namen auch nicht unterschieden werden, daher ist von gleichen Klassennamen abzuraten, wenn sie nicht das gleiche Interface erfüllen.

Ein Argumenttyp wird wie folgt angegeben.

class unbekannt
{
    public test(long A,StringArray B)
    {
        ...
    }
}

Der Typ long ist dabei ein universal Typ, der alles annimmt was übergeben wird. Will man die Klasse Long haben, so muß man auch Long angeben. Groß/KleinSchreibung ist dabei zu unterscheiden!

Als Überladung bezeichnet man die Eigenschaft einer Methode mehrere Implementierungen mit verschiedenen Argumentypen mitgeben zu können. Konkret bedeutet das, daß es in einer Klasse mehrere Methoden gleichen Namens geben kann. Die eigentlich auch gleiche Aufgaben versehen. Ein Beispiel macht dies deutlich:

class unbekannt
{
    public test(long A,StringArray B)
    {
        ...
    }
    public test(long A,String B)
    {
        ...
    }

}

ruft nun eine Klasse die Methode test der unbekannten Klasse auf, so kann Sie wahlweise einen String oder einen StringArray übergeben und erwarten das beides mal das gleiche passiert.

class unbekannt
{
    long A

    public add(Integer B)
    {
        A=A+B.tolong()        // diese Syntax wird noch nicht vom Compiler unterstützt.
    }
    public add(Long B)
    {
        A=A+B.getLong(B)
    }
    public add(Word B)
    {
        A=A+B.tolong(B)
    }

}

Naja, zunächst einmal lassen sich so Methoden zu Gruppen mit gleichen Aufgaben zusammenstellen, so daß sich der Programmierer nur den Namen einer Methode merken muß, um immer die richtige Funktion zubekommen. Ein gutes Beispiel ist hier die "print()" Methode. Damit man nicht für jedes Objekt eine eigene printXXXXX() Methode hat, die man sich ja merken müßte, überläd man einfach die Methode mit einer neuen Implementierung für einen neuen Typen und gut. So steht im Sourcecode später immer nur "print()" statt "printLong()" "printStringArray()" usw.. . Beim Lesen kann man sich also daraufverlassen, wenn man weiß was eine Implementierung von print() macht, dann machen alle anderen das auch. Natürlich nur , wenn der Programmierer der Überladenen Methode das auch so sieht. Das kann letzden Endes kein Compiler der Welt sicherstellen.

Kann man eigentlich alles überladen?

• Da auch Konstruktoren letztlich nur Methoden eines Objektes darstellen, können auch diese Überladen werden. Damit können Objekte schon beim Erzeugen mit NEW() verschiedene Argumente bekommen.
• Das Überladen von Dekonstruktoren ist dagegen verboten! Ein überladener Dekonstruktor kann von DEL() nicht gefunden werden, da eine Übergabe von Argumenten bei einem Dekonstruktor nicht vorgesehen ist und auch nicht sinnvoll ist! Wenn vor einem Dekonstruieren besondere Maßnahmen gemacht werden müssen, die im normalen Dekonstruktor nichts zusuchen haben , oder nur bei bestimmten Objektkonstruktionen durchgeführt werden sollen, dann ist eine eigene Methode dafür zuschreiben, die vor DEL() aufgerufen wird oder der Dekonstruktor besser zu programmieren!

  Ein eventuell später mal gebauter GarbageCollector hätte gar keine Chance ein Objekt korrekt zuzerstören, wenn es mehrere Dekonstruktoren gäbe!.

• Ein Überladen einer Methode X mit den gleichen Argumenttypen und Namen, führt zum Überschreiben einer Methode. So lassen sich Methoden einer SuperKlasse in einer abgeleiteten Klasse überschreiben, wenn dies nötig ist.