Es beginnt normalerweise so:
Code: Select all
@RestController
@RequestMapping("/api/v1")
public class OldControllerV1 {
private final MyService service;
@PostMapping("/process")
public ResultDto process(@RequestBody RequestDto request) {
// ... lots of different validation logic ...
service.execute(request);
}
}
Am Ende sieht es in etwa so aus:
Code: Select all
@RestController
@RequestMapping("/api/v1")
public class OldControllerV1 {
private final MyService service;
@PostMapping("/process")
public ResultDto process(@RequestBody RequestDto request) {
// ... lots of common validation logic ...
service.execute(request, true); // true == old mode
}
}
@RestController
@RequestMapping("/api/v2")
public class NewControllerV2 {
private final MyService service;
@PostMapping("/process")
public ResultDto process(@RequestBody RequestDto request) {
// ... the same validation logic copied from v1, maybe slightly different ...
// The only real difference:
service.execute(request, false); // false == new mode
}
}
Wenn das Projekt SonarQube mit strengen Regeln (Quality Gate) hat, blockiert es den Build aufgrund der Codeduplizierung – die Methodenkörper sind fast identisch.
Das ist eigentlich fair – eine solche Duplizierung verstößt gegen die Grundsätze sauberen Codes und macht zukünftige Änderungen schmerzhaft, da Sie mehrere Stellen bearbeiten müssen.
Die Frage lautet also:
Wie können wir diesen Code richtig umgestalten, damit wir:
- Codeduplizierung eliminieren
- Spring-Annotationen ordnungsgemäß funktionieren
- Die Lösung erweiterbar machen (einfaches späteres Hinzufügen von Version 3, Version 4 usw.)
Mobile version