Version von der überladenen Methode/Klasse

[xylibri]

Hallo,

ich habe folgendes Problem zu lösen:
Es gibt zwei Klassen, A und B, B wird von A abgeleitet und eine der Methoden wird überladen.

Class A 
{
   protected void myMethod()
   {
      doThis();
   }
   protected void yourMethod(){};
   protected void theirMethod(){};
}

Class B extends A 
{
   protected void myMethod()
   {
      doThat();
   }
}

Die Klassen werden von verschiedenen Entwicklern implementiert (EntwicklerA und EntwicklerB), die nichts voneinander wissen.
Später ändert EntwicklerA diee Methode der Klasse A:

Class A 
{
   protected void myMethod()
   {
      doThis();
      yourMethod();
      theirMethod();
   }
   protected void yourMethod(){};
   protected void theirMethod(){};
}

EntwicklerB aktualisiert die KlasseA. Welche Konzepte gibt es, um dem EntwicklerB "mitzuteilen", dass er seine Methode in der KlasseB evtl. aktualisieren soll?

Eine der Möglichkeiten z.B. ist, eine abstracte Methode mit der Versionsnummer hinzuzufügen:

Class A 
{
   ...
   abstract void version1(){}
}

Class B extends A 
{
   protected void myMethod()
   {
      void version1(){}
   }
}

Nach jeder Änderung in der KlasseA ändert EntwicklerA die Methode version1():

Class A 
{
   ...
   abstract void version2(){}
}

Damit bekommt EntwicklerB mit, dass die KlasseA sich geändert hat.

Nachteil: Umständlich, hässlich, 1 Methode für die ganze Klasse (ich hätte das gerne für jede Methode)

Weißt jemand Konzepte, auch externe Tools (z.B. Hashes von Methoden zu erstellen), wie man dieses Problem lösen kann?

Danke im Voraus.

Gruß
xylibri[/code]

 

[Tobias]

Was für ein "kaputter" Entwicklungsstil. Die Schnittstelle sollte stabil bleiben, ansonsten gibt es nur (und immer) Probleme. Da helfen auch so irre Ideen wie eine "Versionsnummer im Methodennamen" nichts.

mpG
Tobias

 

[ms]

Welche Konzepte gibt es, um dem EntwicklerB "mitzuteilen", dass er seine Methode in der KlasseB evtl. aktualisieren soll?

Anruf, Email oder persönlich mit ihm sprechen ...
Wenn sich an der Methodensignatur was geändert hat und beide Entwickler im selben Projekt sitzen dann werden sie hoffentlich miteinander reden bzw. wird Entwickler A hoffentlich keine Compile-Errors einchecken.

Grundsätzlich sollte aber so programmiert werden, dass die vereinbarten Schnittstellen eingehalten werden. Wenn sich also etwas an der Schnittstelle ändert gehört das sowieso kommuniziert und dokumentiert.

Eine der Möglichkeiten z.B. ist, eine abstracte Methode mit der Versionsnummer hinzuzufügen

Bitte vergiss diesen Gedanken schnell wieder.
Abgesehen davon müsste die Klasse A zwangsläufig auch abstrakt werden.

Sehr hilfreich sind auch Unit-Tests und erst dann ins SVN/CVS einchecken, wenn alle diese Tests erfolgreich waren.

ms

 

[maki]

EntwicklerB aktualisiert die KlasseA. Welche Konzepte gibt es, um dem EntwicklerB "mitzuteilen", dass er seine Methode in der KlasseB evtl. aktualisieren soll?

Vor zig tausenden von Jahren haben unsere Vorfahren die Sprache entwickelt, dass wäre eine Möglichkeit.

Modernere, aber nicht unbedingt effizientere Verfahren wären Briefe, mittlerweile auch im elektronischen Format möglich, nennt sich dann email
Andere high-tech wege wie Messenger etc. sind auch denkbar.

Das Problem ist ein organisatorisches, Entwickler, die nix von einander Wissen und gegenseitig denselben Code soweit ändern so dass er nicht mehr kompatibel ist, das ist umständlich, hässlich und äusserst unproffessionel.

 

[ARadauer]

Telefon ;-)

nein ehrlich, die Frage ist ob Entwickler B davon wissen muss?
wenn die Methode noch immer das macht, was sie machen soll und sich an die Schnittstelle hält... wo ist das problem?

Wenn sie was anderes macht... tja dann eine neue methde machen und die alte mit einer annotaition deprecated setzen...

wenn die Änderung wirklich eine Schwerwiegende ist und B unbedingt drauf reagieren muss, dann empfehl ich das Telefon..

 

[Guest]

Was für ein "kaputter" Entwicklungsstil. Die Schnittstelle sollte stabil bleiben, ansonsten gibt es nur (und immer) Probleme. Da helfen auch so irre Ideen wie eine "Versionsnummer im Methodennamen" nichts.

mpG
Tobias

Die Schnittstelle bleibt auch stabil, keine der Signaturen wird verändert. Was ist daran kaputt?

 

[maki]

Wenn die Schnittstelle gleich bleibt, darf es keine Probleme geben wenn die Implmentierung verändert wird.

Dafür gibt es doch Schnittstellen...

 

[xylibri]

Anruf, Email oder persönlich mit ihm sprechen ...
Wenn sich an der Methodensignatur was geändert hat und beide Entwickler im selben Projekt sitzen dann werden sie hoffentlich miteinander reden bzw. wird Entwickler A hoffentlich keine Compile-Errors einchecken.

Nehmen wir an, EntwicklerA und EntwicklerB sitzen in verschiedenen Projekten. Die kommunizieren nicht miteinander, es gibt aber natürlich Changelogs. Die Logs sind so groß, dass EntwicklerB leicht eine Änderung in der Klasse A übersehen kann. Die Schnittstelle ändert sich nicht, aber die Implementierung. Der EntwicklerB macht also ein Update, sieht keine Fehler oder Warnungen und macht sich keine Gedanken. Später bekommt er aber Probleme.

 

[Guest]

Vor zig tausenden von Jahren haben  unsere Vorfahren die Sprache entwickelt, dass wäre eine Möglichkeit.

Modernere, aber nicht unbedingt effizientere Verfahren wären Briefe, mittlerweile auch im elektronischen Format möglich, nennt sich dann email :)
Andere high-tech wege wie Messenger etc. sind auch denkbar.

EntwicklerA weißt weder vom EntwicklerB noch von der KlasseB. Es existieren Changlogs. Die sind aber so groß, dass EntwicklerB die Änderung in der Klasse A schnell übersehen kann.

Das Problem ist ein organisatorisches

Richtig erkannt

Entwickler, die nix von einander Wissen und gegenseitig denselben Code soweit ändern so dass er nicht mehr kompatibel ist, das ist umständlich, hässlich und äusserst unproffessionel.

Das finde ich nicht so. Man ändert nicht denselben Code, nur eine spezielle Implementierung von einer Methode.

 

[Guest]

Wenn die Schnittstelle gleich bleibt, darf es keine Probleme geben wenn die Implmentierung verändert wird.

Dafür gibt es doch Schnittstellen...

Was meinst du mit Problemen? Ja, es wird immer noch kompilieren und starten. Update von der KlasseA ist aber nicht drin. Muss aber rein.

 

[maki]

Ist alles in allem ein Change Management Problem hier.


Automatische Change Notifications wären eine Möglichkeit, welche von einem CI Server versendet werden.

Eine andere wäre, die Klasse in eine jar zu stecken, diese jar als Maven Projkt zu verwalten, dann merken andere Maven Projekte selbstständig (falls die Version das Wort SNAPSHOT enthält), ob es eine neuere Version der "dependency" gibt, lädt diese runter und alles ist gut, Entwickler B hat unter Umständen gar nicht mitbekommen, dass eine neuere Version genutzt wird.

Maven2 mit Continuum würde beides ermöglichen.