Best Practice, wenn es einen Konstruktorwechsel in Java-Objekten gibt

Ich habe eine Klasse, in der viele Parameter wie bei der neuen API-Integration hinzugefügt werden.Best Practice, wenn es einen Konstruktorwechsel in Java-Objekten gibt

Zum Beispiel früher hatte ich eine Klasse mit 4 Parametern:

Integer a; 
String b; 
Map<String, String> c; 
List<Integer> e.

So der Konstruktor war:

public SampleClass(Integer a, 
        String b, 
        Map<String, String> c,  
        List<Integer> e) 
{ 
    this.a = a; 
    this.b = b; 
    this.c = c; 
    this.e = e; 
}

Mehrere Teams haben integriert mit meinem API diesen Konstruktor in ihrem Code verwenden. Nach einiger Zeit wurde dieser Klasse ein neuer Parameter hinzugefügt. das heißt

Double d;

So habe ich einen neuen Konstruktor:

public SampleClass(Integer a, 
        String b, 
        Map<String, String> c, 
        List<Integer> e, 
        Double d) 
{ 
    this.a = a; 
    this.b = b; 
    this.c = c; 
    this.e = e; 
    this.d = d; 
}

Und ich den vorherigen Konstruktor markiert als veraltet. Ich habe den vorherigen Konstruktor nicht entfernt, da der Code des Clients beschädigt würde.

Als die neuen Parameter hinzugefügt werden, habe ich jetzt Konstruktoren mit 5 Parametern.

Gibt es eine bewährte Methode, wie die Konstruktoren veraltet/entfernt werden sollten, damit diese Art von Szenario nicht auftritt?

Quelle

2016-05-16 SIDDHARTH J MEHTA

Nicht sicher, ob dies eine gute Idee ist, aber Sie können Usign [Lombok] (https://projectlombok.org/features/Builder.html) Builder-Muster versuchen. Das einzige Problem (worüber ich mich frage, ob das eine Antwort für dich ist) ist, dass Lombok davon ausgeht, dass Instanzen auf diese Weise erstellt werden: 'Type.builder.param1 (valueParam1) .others (valueOthers). (...) .. . (...). build', was für frühere Kunden nicht verfügbar ist.Aber wenn Sie mit ihnen verhandeln, würden sie das nicht können? Ich meine, Lombok gibt Ihnen einen selbstverwalteten Konstruktor, der unabhängig von der Reihenfolge der Parameter und unabhängig von der Nummer ist. –

Verwenden Sie "Builder-Muster" und in der aktuellen Klasse "Überladung" für Constractoren – Hosseini

Mögliche Duplikate von [Best Practice für die Übergabe vieler Argumente an die Methode?] (Http://stackoverflow.com/questions/2432443/best-practice-for- Passing-Many-Argumente-to-Methode) – Joe

-2

Warum verwenden Sie nicht Variablen Argument Konstruktor. Auf diese Weise können Sie so viele Argumente an den Konstruktor übergeben, wie Sie möchten.

Zum Beispiel:

public double Durchschnitt (Doppel ... Zahlen) {

 double total = 0.0; // initialize total 

     // calculate total using the enhanced for statement 
     for (double d : numbers)    
     total += d;       

     return total/numbers.length; 
    } // end method average

Quelle

2016-05-16 09:10:30 ramasCoder

Grund bitte ???????? – ramasCoder

Antwort stimmt nicht mit Frage überein. –

Bitte erläutern. Meiner Ansicht nach stimmt es überein. – ramasCoder

ändern alt Konstruktor aus:

public SampleClass(Integer a, 
        String b, 
        Map<String, String> c,  
        List<Integer> e) 
{ 
    this.a = a; 
    this.b = b; 
    this.c = c; 
    this.e = e; 
}

public SampleClass(Integer a, 
        String b, 
        Map<String, String> c,  
        List<Integer> e) 
{ 
    //Zero is passed as a default value, but you can pass anything you want 
    this(a,b,c,e,0); 
}

Diese So wird es ca lle den Neuen unter der Haube.

Dennoch haben Sie nicht genügend Informationen darüber geliefert, in welchem Umfang der alte unterstützt werden sollte. Wenn es überhaupt nicht geht, sollten Sie aus dem Code entfernen. Auf diese Weise werden Sie die Benutzer der API erzwingen zu analysieren, was geändert und Draht den neuen Konstruktor.

Wenn Sie dies nicht tun, werden sie halten die alte verwenden, weil Programmierer sind faul :-)

Quelle

2016-05-16 09:11:16 Kelevandos

Es hat nichts mit Faulheit zu tun. Wenn Sie eine API veröffentlichen, geben Sie ein Versprechen ab. Es liegt in Ihrer Verantwortung, dieses Versprechen einzulösen. – biziclop

Ja, aber wenn die API geändert werden muss und sich ändert, sollten die Programmierer verantwortlich sein und analysieren, was sich beim Update auf die neue Version geändert hat. Wenn der Code kompiliert und getestet wird, gehen die meisten von uns davon aus, dass sich nichts geändert hat. Und @Deprecated tut wenig, um das zu bekämpfen :-D Wenn also die Änderung aus irgendeinem Grund entscheidend ist, ist das Entfernen von Methoden aus der API ein guter Weg zu signalisieren, dass der Benutzer analysieren sollte, was sich geändert hat und warum. Und wenn sie das nicht wollen, weil sie der API wie sie sind vertrauen, können sie immer auf den Preis von neuen Features, Änderungen etc. verzichten. C'est la vie – Kelevandos

Sie erwarten nur obligatorische API-Änderungen bei wichtigen Versionsänderungen Das ist die Konvention. Wie ich in einem anderen Kommentar gesagt habe, ist es wichtig, dass Sie eine sehr klare Richtlinie haben, wie Sie mit solchen Instanzen umgehen. – biziclop

Es wäre vorteilhaft, die Open/closed principle zu folgen. Die Klasse, die Sie ursprünglich geschrieben haben, sollte nicht geändert werden, wenn neue Features benötigt werden, sondern eine andere Klasse sollte daraus abgeleitet werden, um ihre Funktionalität zu erweitern.

Quelle

2016-05-16 18:51:36 iluwatar

aber dann wie neue Parameter schrittweise hinzugefügt werden, werden keine neuen Klassen erstellt werden. Wäre es nicht schwierig, alle diese Klassen zu verwalten? –

Best Practice, wenn es einen Konstruktorwechsel in Java-Objekten gibt

Antwort

Verwandte Themen