bin gerade beim Refactoring ung achte dabei auch gleich auf die Lesbarkeit vom Code. Nun haben ich einen SOAP-Service vor mir, deren Parameter ja mindestens eine @WebParam-Annotation benötigen.
Wie schreibt man das jetzt aber lesbar hin?
Beispiele:
public MyResultType methodA(
@XmlElement(required = true) @WebParam(name = "session") final String sessionID,
@XmlElement(required = true) @WebParam(name = "mode") final String mode) {
// do something
}
@WebMethod(operationName = "methodB")
public MyResultType methodB(
@XmlElement(required = true)
@WebParam(name = "session") final String sessionID,
@XmlElement(required = true)
@WebParam(name = "mode") final String mode) {
// do something
}
@WebMethod(operationName = "methodC")
public MyResultType methodC(
@XmlElement(required = true)
@WebParam(name = "session")
final String sessionID,
@XmlElement(required = true)
@WebParam(name = "mode")
final String mode) {
// do something
}
@WebMethod(operationName = "methodD")
public MyResultType methodD(@XmlElement(required = true) @WebParam(name = "session") final String sessionID, @XmlElement(required = true) @WebParam(name = "mode") final String mode) {
// do something
}```
Aktuell nutze ich Variante B, das scheint mir bei vielen Parametern noch mit am übersichtlichsten zu sein.
Die letzte Variante sollte eigentlich nicht zur Diskussion stehen, aber der Vollständigkeit wegen mit aufgeführt.
Puh das sieht ja alles wurschtelig aus… aber ich schwanke da auch zwischen A und B. A fällt imho raus, wenn es zu viele Annotationen werden oder die Variablennamen zu lang sind, so dass es zu breit wird.
Also dem Netbeans-Formatierer ist das egal, wie ich das da stehen habe. Der interessiert sich scheinbar nur für Leerzeichen und Zeilenlänge.
Wenn man sich an den Annotations bei bei Feldern orientiert, müsste man Variante C nutzen. Ich befürchte nur, dass dann die Parameterliste wesentlich mehr Zeilen beansprucht als die eigentliche Methoden-Implementierung.
Aber ein gutes hat es, wenn man beim Refactoring Zeit hat, sich über so etwas gedanken zumachen. Heißt nämlich, dass es sonst keine großen Probleme gibt
public MyResultType methodA(Optional<String> session, String mode) {
// do something
}```
:grampa: Gut, ich kenne noch die Zeiten in denen man XML zur Konfiguration verwendet hat. War lästig, da haben sie gesagt nehmt Annotationen, ist viel besser und übersichtlicher.
Über Optional kann man streiten, es gut oder schlecht finden, aber um damit zwischen required = true|false zu unterscheiden ist mir das lieber, als eine Annotation. Per Konvention würde das Framework, davon ausgehen, dass ein Optional für required = false steht und ansonsten true anzunehmen ist. Die resultierende Behandlung von Optional ist ansonsten eh vorzunehmen.
Anstelle von name kann man wiederum auch die Konvention nehmen, dass name und Variablenbezeichner identisch sein müssen. Schon fällt eine weitere Annotation weg.[/OT]
Hab noch nie wirklich mit SOAP gearbeitet. Aber: würde es klappen wenn man gegen ein Interface programmiert und dorthin die Annotation auslagert? Dann würde ichs nämlich mit einem extra Interface machen und (weil ichs am besten zu lesen finde) Variante A. Die implementierende Klasse enthält dann keine der Annotationen mehr und bleibt dadurch übersichtlicher.
Naja, in so einem Fall brauchste halt ne Guideline - wie du mit Annotationen umzugehen hast. Wir im Betrieb bauen halt gerade unsere REST-Services so, dass Interfaces Annotiert werden und die implementierende Klasse frei davon bleibt (vor allem weil man wohl gefahr läuft, dass sonst die vererbten Annotationen komplett ignoriert werden können).
