Optionale Werte behandeln

Sep 08 2020

Ich habe eine Situation, in der es Werte in der Datenbank geben könnte und nicht, weshalb ich optional zurückgebe, sodass das Antwortobjekt, das zur Benutzeroberfläche zurückkehrt, abhängig von den vorhandenen oder nicht vorhandenen Werten unterschiedlich sein kann.

Beispiele:

 new UserLogsResponse(auditEntity.get().getTimestamp(), latestRetrievedDocumentDateAndTime.get(),emailFromAuditMessage, tokeDateAndTimeStamp)

Wie Sie sehen können, wo dort object.get () steht, erhalte ich Wert aus dem optionalen.

Ich möchte zahlreiche if-Blöcke vermeiden, die sagen, ob der Wert vorhanden ist, und dann dem Antwortkonstruktor ein Objekt hinzufügen, sodass ich derzeit nicht überprüfe, ob das optionale mit vorhanden ist, und Werte an den Konstruktor eines Antwortobjekts übergebe und innerhalb des Konstruktors bestimmte Überprüfungen durchführe und Basierend auf Überprüfungen gebe ich entweder null zurück oder mache einige Operationen mit einem Wert von nicht null und es ist in Ordnung, es erledigt den Job, aber Code sieht nicht gut aus, da er get () in optionalen Objekten hervorhebt, wenn ich nicht mit Überprüfungen fortfahre, bevor ich ihn an my übergebe Antwortobjekt.

@Getter
@Setter
@JsonInclude(JsonInclude.Include.NON_NULL)
public class UserLogsResponse {

    private final String latestSentEmailStamp;
    private final String latestDocumentRetrievalStamp;
    private final String privateEmail;
    private final String loginTimeStamp;

    public UserLogsResponse(LocalDateTime latestSentEmailStamp, LocalDateTime latestDocumentRetrievalStamp, String privateEmail, LocalDateTime loginTimeStamp) {
        this.latestSentEmailStamp = latestSentEmailStamp == null ? null : LocalDateFormatter.ddMMyyAtHHmm(latestSentEmailStamp);
        this.latestDocumentRetrievalStamp = latestDocumentRetrievalStamp == null ? null : LocalDateFormatter.ddMMyyAtHHmm(latestDocumentRetrievalStamp);
        this.privateEmail = privateEmail == null ? null : new Email(privateEmail).hideSomeEmailCharacters();
        this.loginTimeStamp = loginTimeStamp == null ? null : LocalDateFormatter.ddMMyyAtHHmm(loginTimeStamp);
    }
}


  public UserLogsResponse getUserLogs(HttpServletRequest request) {
    UserEntity userEntity = currentUser.get();
    Optional<LocalDateTime> tokeDateAndTimeStamp = tokenService.getPreviousLoginStamp(request,userEntity, LocalDateTime.now());
    Optional<LocalDateTime> latestRetrievedDocumentDateAndTime = auditRepository.getLatestRetrievalDocumentDateAndTime(userEntity.getId());
    Optional<AuditEntity> auditEntity = auditRepository.getLatestSendEmailDateAndTime(userEntity.getId());
    String emailFromAuditMessage = new AuditMessageExtractor(auditEntity.get().getMessage()).extractEmail();
    return tokeDateAndTimeStamp.map(localDateTime -> new UserLogsResponse(auditEntity.get().getTimestamp(), latestRetrievedDocumentDateAndTime.get(), emailFromAuditMessage, localDateTime))
            .orElseGet(() -> new UserLogsResponse(auditEntity.get().getTimestamp(), latestRetrievedDocumentDateAndTime.get(),emailFromAuditMessage, null));
}

Würde mich über Vorschläge freuen, da ich sagte, dass alles funktioniert und es gut ist, aber wenn ich ein anderer Entwickler wäre und optionale Objekte ohne ifPresent-Prüfung sehen würde, wäre das verwirrend.

Antworten

Artjom Sep 08 2020 at 17:44

Ah sorry Leute, ich habe eine Lösung gefunden:

Führt einfach Folgendes aus und Nullprüfungen werden im Konstruktor behandelt

 LocalDateTime tokeDateAndTimeStamp = tokenService.getPreviousLoginStamp(request,userEntity, LocalDateTime.now()).orElseGet(null);
    LocalDateTime latestRetrievedDocumentDateAndTime = auditRepository.getLatestRetrievalDocumentDateAndTime(userEntity.getId()).orElseGet(null);
    AuditEntity auditEntity = auditRepository.getLatestSendEmailDateAndTime(userEntity.getId()).orElseGet(null);
nullTerminator Sep 08 2020 at 18:02

Dies scheint den Code zu vereinfachen, bewirkt jedoch, dass die UserLogsResponseKlasse sowohl an den Token-Service als auch an das Audit-Repository gekoppelt wird, was das Testen ohne Verspotten oder Stubben erschwert. Möchten Sie die @SetterAnmerkung auch wirklich ? Sollten diese Elemente nach dem Ausführen des Konstruktors schreibgeschützt sein?