Code-Case-Sharing für die Konstruktion und Verifizierung von Java- und Ceylon-Objekten

Beim Konvertieren von Java-Code in Ceylon-Code stoße ich manchmal auf Situationen, in denen einige Java-Klassenkonstruktoren Validierung und Initialisierung verwechseln. Lassen Sie uns anhand eines einfachen, aber konstruierten Codebeispiels veranschaulichen, was ich meine.

Einiger schlechter Code

Betrachten Sie die folgende Java-Klasse. (Alter, schreib so einen Code nicht zu Hause)

public class Period {
    private final Date startDate;
    private final Date endDate;
    //returns null if the given String
    //does not represent a valid Date
    private Date parseDate(String date) {
       ...
    }
    public Period(String start, String end) {
        startDate = parseDate(start);
        endDate = parseDate(end);
    }
    public boolean isValid() {
        return startDate!=null && endDate!=null;
    }
    public Date getStartDate() {
        if (startDate==null) 
            throw new IllegalStateException();
        return startDate;
    }
    public Date getEndDate() {
        if (endDate==null)
            throw new IllegalStateException();
        return endDate;
    }
}

Hey, ich habe dich schon einmal gewarnt, es ist gekünstelt. Tatsächlich ist es jedoch nicht ungewöhnlich, so etwas in echtem Java-Code zu finden.

Das Problem hierbei ist, dass wir, selbst wenn die Validierung des Eingabeparameters (in der versteckten parseDate()-Methode) fehlschlägt, immer noch eine Instanz von Period erhalten. Aber der von uns erhaltene Zeitraum ist kein „gültiger“ Zustand. Genau genommen, was meine ich?

Nun, ich würde sagen, dass sich ein Objekt in einem inaktiven Zustand befindet, wenn es nicht sinnvoll auf allgemeine Vorgänge reagieren kann. In diesem Beispiel lösen getStartDate() und getEndDate() eine IllegalStateException aus, eine Situation, die meiner Meinung nach keinen „Sinn ergibt“.

Wenn wir dieses Beispiel von der anderen Seite betrachten, haben wir beim Entwerfen von Periode einen Fehler vom Typ Sicherheit. Ungeprüfte Ausnahmen stellen eine „Lücke“ im Typsystem dar. Daher wäre ein besserer typsicherer Entwurf für Period ein Entwurf, der keine ungeprüften Ausnahmen verwendet – was in diesem Fall bedeutet, dass keine IllegalStateException ausgelöst wird.

(Tatsächlich ist es in echtem Code wahrscheinlicher, dass ich auf eine getStartDate()-Methode stoße, die nicht nach Null sucht und nach dieser Codezeile eine NullPointerException verursacht, was noch schlimmer ist.)

Wir können die obige Periodenklasse problemlos in eine Klasse im Ceylon-Stil umwandeln:

shared class Period(String start, String end) {
    //returns null if the given String
    //does not represent a valid Date
    Date? parseDate(String date) => ... ;
    value maybeStartDate = parseDate(start);
    value maybeEndDate = parseDate(end);
    shared Boolean valid
        => maybeStartDate exists 
        && maybeEndDate exists;
    shared Date startDate {
        assert (exists maybeStartDate);
        return maybeStartDate;
    }
    shared Date endDate {
        assert (exists maybeEndDate);
        return maybeEndDate;
    }
}

Natürlich treten bei diesem Code auch die gleichen Probleme auf wie beim ursprünglichen Java-Code. Die beiden Assert-Symbole schreien uns an, dass es ein Problem mit der Typsicherheit des Codes gibt.

Java-Code verbessern

Wie können wir diesen Code in Java verbessern? Nun, hier ist ein Beispiel, bei dem die vielgeschmähten geprüften Ausnahmen von Java eine sehr vernünftige Lösung sein können! Wir können Period leicht modifizieren, um eine geprüfte Ausnahme von seinem Konstruktor auszulösen:

public class Period {
    private final Date startDate;
    private final Date endDate;
    //throws if the given String
    //does not represent a valid Date
    private Date parseDate(String date)
            throws DateFormatException {
       ...
    }
    public Period(String start, String end) 
            throws DateFormatException {
        startDate = parseDate(start);
        endDate = parseDate(end);
    }
    public Date getStartDate() {
        return startDate;
    }
    public Date getEndDate() {
        return endDate;
    }
}

Mit dieser Lösung erhalten wir nun keinen Period in einem inaktiven Zustand. Der Code, der Period instanziiert, ist dafür verantwortlich Behandlung ungültiger Eingabesituationen durch den Compiler, der eine DateFormatException-Ausnahme abfängt.

try {
    Period p = new Period(start, end);
    ...
}
catch (DateFormatException dfe) {
    ...
}

Dies ist eine schöne, perfekte und korrekte Verwendung von geprüften Ausnahmen. Leider sehe ich selten Java-Code, der geprüfte Ausnahmen wie die oben genannten verwendet.

Ceylon-Code verbessern

Was ist also mit Ceylon? In Ceylon gibt es keine geprüften Ausnahmen, daher müssen wir eine andere Lösung finden. Normalerweise ruft Ceylon in Situationen, in denen der Aufruf einer -Funktion in Java eine geprüfte Ausnahme auslöst, die Funktion auf und gibt einen Union-Typ zurück. Da ein Klasseninitialisierer keinen anderen Typ als die Klasse selbst zurückgibt, müssen wir eine gemischte Initialisierungs-/Validierungslogik in eine Factory-Funktion extrahieren.

//returns DateFormatError if the given 
//String does not represent a valid Date
Date|DateFormatError parseDate(String date) => ... ;
shared Period|DateFormatError parsePeriod
        (String start, String end) {
    value startDate = parseDate(start);
    if (is DateFormatError startDate) {
        return startDate;
    }
    value endDate = parseDate(end);
    if (is DateFormatError endDate)  {
        return endDate;
    }
    return Period(startDate, endDate);
}
shared class Period(startDate, endDate) {
    shared Date startDate;
    shared Date endDate;
}

Gemäß dem Typsystem ist der Aufrufer verpflichtet, DateFormatError zu behandeln:

value p = parsePeriod(start, end);
if (is DateFormatError p) {
    ...
}
else {
    ...
}

Alternativ, wenn uns die tatsächlichen Probleme mit dem angegebenen Datumsformat egal sind ( (was möglich ist, vorausgesetzt, dass unserem funktionierenden Initialisierungscode diese Informationen fehlen), können wir Null anstelle von DateFormatError verwenden:

//returns null if the given String 
//does not represent a valid Date
Date? parseDate(String date) => ... ;
shared Period? parsePeriod(String start, String end)
    => if (exists startDate = parseDate(start), 
           exists endDate = parseDate(end))
       then Period(startDate, endDate)
       else null;
shared class Period(startDate, endDate) {
    shared Date startDate;
    shared Date endDate;
}

Der Factory-Funktionsansatz ist gelinde gesagt ausgezeichnet, denn im Allgemeinen bei der Validierung Logik und bietet eine bessere Isolierung zwischen Objektinitialisierungen. Dies ist besonders in Ceylon nützlich, wo der Compiler der Objektinitialisierungslogik einige sehr strenge Einschränkungen hinzufügt, um sicherzustellen, dass alle Felder eines Objekts nur einmal zugewiesen werden.

Das obige ist der detaillierte Inhalt vonCode-Case-Sharing für die Konstruktion und Verifizierung von Java- und Ceylon-Objekten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!