OOP Externe Klasse erweitern (ohne Vererbung!!)

[chackie-lee]

Hallo zusammen,

ich bin neu im Forum und komme aus der Ecke C/C++ und Python.
Daher entschuldigt bitte, falls mein Java-Wording noch nicht perfekt ist.

Bei meinen Problem geht es um folgendes Szenario:
Ich muss ein paar Klassen eines Java-Programmes erweitern, so dass dieses Programm als externe Library in ein neues Projekt eingebunden werden kann.
Dabei darf ich das Programm im Quellcode nicht anfassen sondern es nur als JAR in mein neues Projekt einbinden.
Ich möchte im neuen Projekt dieselbe Package-Struktur und denselben Klassen-Namen der Original-Klassen verwenden. Dadurch können Kollegen, die das alte Programm kennen, wie gewohnt ihre Klassen anlegen und nun auch auf die neuen Funktionen zurückgreifen.

Im Prinzip stelle ich mir folgendes vor (Pseudo-Code):
Altes Programm mit zu erweiternder Klasse (wird als Jar eingebunden):

package com.company.testen;
public class test
{
  public String auto() ...
  public String fahrrad() ...
}

Neues Projekt/Library:

package com.company.testen;
public class test extends test
{
  public String schiff() ...
  public String rakete() ...
}

Projekt der Kollegen:

import com.company.testen;
public class Main {
  public static void main() {

    test pruefen = new test();

    pruefen.auto()
    pruefen.fahrrad()
    pruefen.schiff()
    pruefen.rakete()
  }
}

So wie ich es beschrieben habe, kann man es leider nicht programmieren.

Wie gesagt, den Quellcode des jar-Files darf ich leider nicht anfassen.

Folgende Ideen sind mir bis jetzt gekommen:
- Klasse mit Vererbung und neuen Funktionen erstellen. Alte Klassen entladen und neue Klassen an deren stelle laden (Selber Speicherbereich).
- Irgendeine Java-Funktion, die umgekehrte Vererbung ermöglicht. Ich zwinge der Eltern-Klasse quasi meine neuen Funktionen auf (es wird keine neue Klasse erstellt).

Mir ist klar, dass das ganze wahrscheinlich nicht sehr "sauber" ist.

Hat jemand eine Idee?

Dank im Vorraus,
chackie-lee

 

[nroz]

Verstehe ich das richtig.

Du hast Projekt A (altes Modul) und nun arbeitest du an Projekt B (deine Sourcen + altes Modul) die sich nach aussen
geben sollen wie das Projekt A nur das du in Projekt A nichts ändern darfst?

Wenn dem so ist würde ich dir das Adapter Pattern vorschlagen.

public class MyAdapter 
{
	private OldClass tehOldey = new OldClass();
	
	public String schiff()
	{
		return tehOldey.schiff();
	}
	
	public String rakete()
	{
		return tehOldey.rakete();
	}
	
	public String auto()
	{
		// neue Funktion
		return "möp";
	}
	
	public String fahrrad()
	{
		return "tröt";
	}
}

 

[slawaweis]

Wie gesagt, den Quellcode des jar-Files darf ich leider nicht anfassen.

LGPL?

Folgende Ideen sind mir bis jetzt gekommen:
- Klasse mit Vererbung und neuen Funktionen erstellen. Alte Klassen entladen und neue Klassen an deren stelle laden (Selber Speicherbereich).

das wäre eine Möglichkeit, mit verschiedenen Classloadern. Falls aber das alte API neue Funktionen bekommt, braucht man die neuen Signaturen für das Kompilieren und da könnte es Probleme mit gleichen Packages geben.

- Irgendeine Java-Funktion, die umgekehrte Vererbung ermöglicht. Ich zwinge der Eltern-Klasse quasi meine neuen Funktionen auf (es wird keine neue Klasse erstellt).

Java bietet so was nicht an. Die einzige Möglichkeit das zu machen wäre, den Binärcode einer Klasse zu laden, zu verändern und daraus im Speicher eine neue Klasse zu erstellen. Aber das wäre schon Reverse Engineering in Echtzeit.

Der einfachste und sicherste Weg wäre, sich einen neuen Namensraum zu definieren, z.B. "xyz.com.company.testen" und darin das gesamte API von "com.company.testen" über Vererbung oder Delegation nachzubilden, so wie man es haben möchte:

package xyz.com.company.testen;

public class Test extends com.company.testen.Test
{
  public String schiff() ...
  public String rakete() ...
}

Dann muss man nur noch in allen Java-Klassen, welche das alte API verwenden, die Package-Namen austauschen: "com.company.testen" -> "xyz.com.company.testen". Wenn man das gesamte API nachgebildet hat, sollte es keine Probleme geben. Mit einem Ant-Script könnte man es sogar automatisieren und zwischen der alten und neuen Version hin und her schalten.

Slawa

 

[Michael...]

Ich möchte im neuen Projekt dieselbe Package-Struktur und denselben Klassen-Namen der Original-Klassen verwenden.

Grundsätzlich: Sehr schlechte Idee. Zumal es sowieso nicht funktioniert, wenn Du das alte Package mit einbindest.

 

[chackie-lee]

Schon ein mal Danke für die schnellen Antworten zum Problem.

Die vorgestellten Lösungen beinhalten leider, dass es eine neue Klasse mit den alten Funktionen gibt oder dass eine neue Package-Struktur mit demselben Klassen-Namen erstellt wird.
In beiden Fällen muss der Kollege seinen Code zum Einbinden der neuen Funktionen (inkl. den alten) also anpassen.

Genau das möchte ich ja gerne verhindern.

Grundsätzlich: Sehr schlechte Idee. Zumal es sowieso nicht funktioniert, wenn Du das alte Package mit einbindest.

Soweit ich weiß, kann ich doch ein eingebundenes Package mit neuen Klassen erweitern, in dem ich im Projekt genau dieselbe Package-Struktur verwende. Oder ist das doch nicht möglich?

Falls es nicht möglich ist, dann kann ich wirklich nur auf eine der vorgestellten Lösungen von nroz oder slawaweis zurückgreifen.

 

[Michael...]

Soweit ich weiß, kann ich doch ein eingebundenes Package mit neuen Klassen erweitern, in dem ich im Projekt genau dieselbe Package-Struktur verwende.

Mit neuen Klassen ist das durchaus möglich - aber unschön. Aber wenn ich das richtig verstanden habe, willst Du ja auch Klassen mit dem selben/bereits vergebenen Namen erstellen - und zusätzlich noch von den alten erben?

 

[chackie-lee]

Hallo Michael,

richtig, genau das ist mein Anliegen. Schön auf den Punkt gebracht.
Aber ich höre aus deinen Posting raus, dass das wohl nicht möglich ist.

 

[nroz]

Schon ein mal Danke für die schnellen Antworten zum Problem.

Die vorgestellten Lösungen beinhalten leider, dass es eine neue Klasse mit den alten Funktionen gibt oder dass eine neue Package-Struktur mit demselben Klassen-Namen erstellt wird.
In beiden Fällen muss der Kollege seinen Code zum Einbinden der neuen Funktionen (inkl. den alten) also anpassen.

Genau das möchte ich ja gerne verhindern.



Soweit ich weiß, kann ich doch ein eingebundenes Package mit neuen Klassen erweitern, in dem ich im Projekt genau dieselbe Package-Struktur verwende. Oder ist das doch nicht möglich?

Falls es nicht möglich ist, dann kann ich wirklich nur auf eine der vorgestellten Lösungen von nroz oder slawaweis zurückgreifen.

Wenn vernünftig gegen Interfaces implementiert wurde ist so eine Änderung normalerweise kein großer Aufwand. ;-)

 

[slawaweis]

Die vorgestellten Lösungen beinhalten leider, dass es eine neue Klasse mit den alten Funktionen gibt oder dass eine neue Package-Struktur mit demselben Klassen-Namen erstellt wird.
In beiden Fällen muss der Kollege seinen Code zum Einbinden der neuen Funktionen (inkl. den alten) also anpassen.

Genau das möchte ich ja gerne verhindern.

inzwischen habe ich das Gefühl, dass es darum geht die Bibliotheken heimlich auszutauchen, ohne dass es die Kollegen überhaupt merken. Sorry, aber zum Leben der Softwareentwickler und Programmierer gehört es, dass die Werkzeuge und Bibliotheken sich mit der Zeit weiterentwickeln. Man kann doch nicht sagen: "wir arbeiten nur mit dem alten API von Heute bis zu unserer Rente und rühren keinen Finger, um es zu modernisieren". Wenn man einmal an dem Punkt angekommen ist wo dieser Thread begann, dass man bestehende Klassen zu Laufzeit dynamisch erweitern will, dann stimmt irgendwas mit dem Design der Software nicht mehr. Entweder man passt sich dem Fortschritt an und weist die Kollegen an eine neue Bibliothek zu lernen und zu nutzen, oder man beginnt die nächste Generation der Software zu entwickeln, wo man gleich ein neues modernes Design festlegt, um die alten Probleme über Bord zu werfen. Man könnte das ganze sogar auf einer anderen Programmiersprache aufbauen, wenn Java nicht mehr ausreicht.

Noch mal zu meinem Vorschlag. Wenn man das API mit einem anderen Namespace nachbildet, muss man nichts mehr machen, als die Namespacenamen in den Quelltextdateien auszutauchen. Das kann man ganz leicht automatisieren, so dass die Kollegen nichts machen müssen, außer vielleicht davon zu erfahren. Man könnte z.B. den ganzen Quelltext in der Versionsverwaltung anpassen oder auf jedem Computer einzeln, über ein Script.

Slawa