1. Extract Method

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
import java.util.List;
// Refactoring: Extract Method
// Zweck: Rabattberechnung benennen und die Hauptmethode auf einer Abstraktionsebene halten.
public final class InvoiceTotalCalculator {
  public BigDecimal total(List<BigDecimal> positions, boolean premium) {
    BigDecimal subtotal = positions.stream().reduce(BigDecimal.ZERO, BigDecimal::add);
    return subtotal.subtract(discountFor(subtotal, premium));
  }
  private BigDecimal discountFor(BigDecimal subtotal, boolean premium) {
    return premium ? subtotal.multiply(new BigDecimal("0.10")) : BigDecimal.ZERO;
  }
}

2. Inline Method

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
// Refactoring: Inline Method
// Zweck: Eine bedeutungslose Weiterleitung entfernen, wenn der Ausdruck selbst klarer ist.
public final class CustomerPriority {
  public boolean isPriority(int openCases, boolean vip) {
    return vip || openCases >= 5;
  }
}

3. Extract Variable

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
// Refactoring: Extract Variable
// Zweck: Fachliche Teilbedingungen sichtbar und unabhängig prüfbar machen.
public final class ShipmentEligibility {
  public boolean eligible(int weightKg, boolean hazardous, boolean addressVerified) {
    boolean withinWeightLimit = weightKg <= 30;
    boolean safeGoods = !hazardous;
    return withinWeightLimit && safeGoods && addressVerified;
  }
}

4. Inline Variable

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
// Refactoring: Inline Variable
// Zweck: Eine Variable entfernen, die keinen zusätzlichen Fachbegriff trägt.
public final class OrderReference {
  public String format(String tenant, long sequence) {
    return tenant.toUpperCase() + "-" + sequence;
  }
}

5. Change Function Declaration

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Change Function Declaration
// Zweck: Namen und Parameter machen den Autorisierungsvertrag explizit.
public final class PaymentAuthorizer {
  public Authorization authorizePayment(String accountId, BigDecimal amount) {
    if (accountId == null || accountId.isBlank()) throw new IllegalArgumentException("accountId");
    return new Authorization(accountId, amount, amount.signum() > 0);
  }
  public record Authorization(String accountId, BigDecimal amount, boolean approved) {}
}

6. Encapsulate Variable

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal; import java.util.Map; import java.util.concurrent.ConcurrentHashMap;
// Refactoring: Encapsulate Variable
// Zweck: Änderungen validieren und interne Repräsentation verbergen.
public final class ExchangeRateTable {
  private final Map<String, BigDecimal> rates = new ConcurrentHashMap<>();
  public void update(String currency, BigDecimal rate) {
    if (rate.signum() <= 0) throw new IllegalArgumentException("rate");
    rates.put(currency, rate);
  }
  public BigDecimal rateFor(String currency) { return rates.get(currency); }
}

7. Rename Variable

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
// Refactoring: Rename Variable
// Zweck: Fachliche Bedeutung statt Implementierungsabkürzungen ausdrücken.
public final class RiskScore {
  public int calculate(int missedPayments, int fraudSignals) {
    int paymentRiskPoints = missedPayments * 10;
    int fraudRiskPoints = fraudSignals * 25;
    return paymentRiskPoints + fraudRiskPoints;
  }
}

8. Introduce Parameter Object

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.time.LocalDate;
// Refactoring: Introduce Parameter Object
// Pattern: Value Object
// Zweck: Zusammengehörige Lieferparameter konsistent validieren und weiterreichen.
public final class DeliveryPlanner {
  public String plan(DeliveryRequest request) {
    return request.postalCode()+":"+request.requestedDate()+":"+request.express();
  }
  public record DeliveryRequest(String postalCode, LocalDate requestedDate, boolean express) {
    public DeliveryRequest { if (postalCode == null || postalCode.isBlank()) throw new IllegalArgumentException("postalCode"); }
  }
}

9. Combine Functions into Class

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
// Refactoring: Combine Functions into Class
// Zweck: Berechnungen besitzen einen gemeinsamen unveränderlichen Fachkontext.
public record TemperatureReading(double celsius) {
  public double fahrenheit() { return celsius * 9 / 5 + 32; }
  public boolean freezing() { return celsius <= 0; }
}

10. Combine Functions into Transform

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Combine Functions into Transform
// Zweck: Abgeleitete Werte in einem deterministischen Transformationsschritt bündeln.
public final class OrderSummaryTransform {
  public Summary transform(BigDecimal net, BigDecimal taxRate) {
    BigDecimal tax = net.multiply(taxRate);
    return new Summary(net, tax, net.add(tax));
  }
  public record Summary(BigDecimal net, BigDecimal tax, BigDecimal gross) {}
}

11. Split Phase

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
// Refactoring: Split Phase
// Zweck: Technische Aufbereitung und fachliche Entscheidung getrennt verändern und testen.
public final class ShipmentImportPhases {
  public ImportResult importLine(String line) {
    ParsedShipment parsed = parse(line);
    return classify(parsed);
  }
  private ParsedShipment parse(String line) {
    String[] parts = line.split(";");
    return new ParsedShipment(parts[0].trim(), Integer.parseInt(parts[1].trim()));
  }
  private ImportResult classify(ParsedShipment shipment) {
    return new ImportResult(shipment.reference(), shipment.weightKg() <= 30);
  }
  record ParsedShipment(String reference, int weightKg) {}
  public record ImportResult(String reference, boolean standardRoute) {}
}

12. Replace Derived Variable with Query

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal; import java.util.ArrayList; import java.util.List;
// Refactoring: Replace Derived Variable with Query
// Zweck: Keine synchron zu haltende Gesamtsumme speichern.
public final class CartTotalQuery {
  private final List<BigDecimal> prices = new ArrayList<>();
  public void add(BigDecimal price) { prices.add(price); }
  public BigDecimal total() { return prices.stream().reduce(BigDecimal.ZERO, BigDecimal::add); }
}

13. Change Reference to Value

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
// Refactoring: Change Reference to Value
// Pattern: Value Object
// Zweck: Adressen werden unveränderlich und anhand ihres Inhalts verglichen.
public record CustomerAddressValue(String street, String city, String postalCode) {
  public CustomerAddressValue {
    if (street == null || city == null || postalCode == null) throw new IllegalArgumentException("address");
  }
}

14. Change Value to Reference

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.util.Map; import java.util.concurrent.ConcurrentHashMap;
// Refactoring: Change Value to Reference
// Pattern: Identity Map / Registry
// Zweck: Pro Kunden-ID wird eine kanonische Instanz verwendet.
public final class CustomerReferenceRegistry {
  private final Map<String, Customer> customers = new ConcurrentHashMap<>();
  public Customer customer(String id, String name) { return customers.computeIfAbsent(id, key -> new Customer(key,name)); }
  public static final class Customer { private final String id; private final String name; Customer(String id,String name){this.id=id;this.name=name;} public String id(){return id;} public String name(){return name;} }
}

15. Split Loop

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal; import java.util.List;
// Refactoring: Split Loop
// Zweck: Zwei unabhängige Fragen getrennt lesbar und veränderbar machen.
public final class OrderAnalysisLoops {
  public BigDecimal total(List<BigDecimal> amounts) { BigDecimal total=BigDecimal.ZERO; for (var amount:amounts) total=total.add(amount); return total; }
  public long expensiveCount(List<BigDecimal> amounts) { long count=0; for (var amount:amounts) if(amount.compareTo(new BigDecimal("100"))>0) count++; return count; }
}

16. Slide Statements

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Slide Statements
// Zweck: Validierung und Normalisierung stehen direkt vor ihrer Verwendung.
public final class InvoicePreparation {
  public BigDecimal prepare(BigDecimal net, BigDecimal taxRate) {
    if (net.signum() < 0) throw new IllegalArgumentException("net");
    BigDecimal normalizedRate = taxRate.stripTrailingZeros();
    return net.add(net.multiply(normalizedRate));
  }
}

17. Replace Loop with Pipeline

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal; import java.util.List;
// Refactoring: Replace Loop with Pipeline
// Zweck: Filter, Abbildung und Aggregation als deklarative Schritte sichtbar machen.
public final class ActiveCustomerRevenue {
  public BigDecimal calculate(List<Customer> customers) {
    return customers.stream().filter(Customer::active).map(Customer::revenue).reduce(BigDecimal.ZERO,BigDecimal::add);
  }
  public record Customer(boolean active, BigDecimal revenue) {}
}

18. Remove Dead Code

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Remove Dead Code
// Zweck: Nur die tatsächlich unterstützte Preisregel bleibt Teil des Vertrags.
public final class CurrentPricingRule {
  public BigDecimal price(BigDecimal base, boolean premium) { return premium ? base.multiply(new BigDecimal("0.90")) : base; }
}

19. Separate Query from Modifier

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
import java.util.HashSet; import java.util.Set;
// Refactoring: Separate Query from Modifier
// Command-Query Separation: Abfrage und Zustandsänderung sind getrennt.
public final class ReservationLedger {
  private final Set<String> reserved = new HashSet<>();
  public boolean isReserved(String id) { return reserved.contains(id); }
  public void reserve(String id) { if(!reserved.add(id)) throw new IllegalStateException("already reserved"); }
}

20. Parameterize Function

Vorhandener Java-21-Zielcode

package com.aydinsude.workbench.catalog;
// Refactoring: Parameterize Function
// Strategy-Parameter: Der Grenzwert ist Teil des Aufrufvertrags statt duplizierter Methoden.
public final class ThresholdClassifier {
  public boolean reaches(int score, int threshold) { return score >= threshold; }
}

21. Replace Parameter with Query

Sicherer Refactoring-Ablauf

1. Verhalten mit Charakterisierungstests absichern.
2. Die interne Abfrage zunächst zusätzlich zum Parameter einführen und beide Werte vergleichen.
3. Alle Aufrufer auf den vereinfachten Vertrag umstellen.
4. Den redundanten Parameter entfernen und die Abfrage hinter einer klar benannten Methode kapseln.

Enterprise-Java-Einordnung

Eine Versandberechnung liest Expressstatus und Kundensegment aus dem typisierten Auftrag, statt einen extern berechneten Multiplikator entgegenzunehmen.

Teststrategie

Tests sollten Standard-, Express- und Grenzfälle abdecken und beweisen, dass kein Aufrufer mehr einen abweichenden Faktor einschleusen kann.

ShippingFeeQuery.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Replace Parameter with Query
// Zweck: Der Gebührenfaktor wird aus dem Auftrag statt vom Aufrufer geliefert.
public final class ShippingFeeQuery {
  public BigDecimal fee(Order order) {
    return order.baseFee().multiply(order.express() ? new BigDecimal("1.50") : BigDecimal.ONE);
  }
  public record Order(BigDecimal baseFee, boolean express) {}
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

22. Replace Query with Parameter

Sicherer Refactoring-Ablauf

1. Die versteckte Abfrage identifizieren und ihren fachlichen Typ bestimmen.
2. Den Wert zunächst als zusätzlichen Parameter einführen.
3. Aufrufer so umbauen, dass sie den Wert an einer klaren Systemgrenze beschaffen.
4. Den internen Zugriff entfernen und Tests mit expliziten Werten ergänzen.

Enterprise-Java-Einordnung

Eine Fristberechnung erhält ein Instant oder eine Clock-Schnittstelle, statt LocalDateTime.now() tief im Domain-Code aufzurufen.

Teststrategie

Tests verwenden feste Zeitpunkte, verschiedene Zeitzonen und Grenzwerte rund um Fristwechsel.

TaxCalculationParameter.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Replace Query with Parameter
// Dependency Injection: Der Steuersatz ist explizite Eingabe statt versteckter Abfrage.
public final class TaxCalculationParameter {
  public BigDecimal gross(BigDecimal net, BigDecimal taxRate) {
    return net.add(net.multiply(taxRate));
  }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

23. Preserve Whole Object

Sicherer Refactoring-Ablauf

1. Die benötigten Werte und ihre Quelle dokumentieren.
2. Das vollständige Objekt zusätzlich übergeben und intern zunächst nur lesend verwenden.
3. Einzelparameter schrittweise durch Objektzugriffe ersetzen.
4. Redundante Parameter entfernen und die Abhängigkeit auf eine schmale fachliche Sicht begrenzen.

Enterprise-Java-Einordnung

Eine Kreditprüfung erhält den LoanApplication-Kontext statt Einkommen, Laufzeit, Betrag und Kundengruppe als lose Einzelparameter.

Teststrategie

Tests prüfen, dass nur relevante Felder ausgewertet werden und Änderungen an irrelevanten Feldern das Ergebnis nicht beeinflussen.

EligibilityPreserveWholeObject.java

package com.aydinsude.workbench.catalog;
// Refactoring: Preserve Whole Object
// Zweck: Die Regel erhält den vollständigen Antrag und bleibt bei neuen Kriterien stabil.
public final class EligibilityPreserveWholeObject {
  public boolean eligible(Application application) {
    return application.age() >= 18 && application.annualIncome() >= 30000 && !application.blocked();
  }
  public record Application(int age, int annualIncome, boolean blocked) {}
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

24. Remove Flag Argument

Sicherer Refactoring-Ablauf

1. Alle Flagwerte und Aufrufstellen erfassen.
2. Für die fachlich unterschiedlichen Absichten sprechende Methoden einführen.
3. Gemeinsame Teile extrahieren, ohne die Varianten künstlich zusammenzuhalten.
4. Aufrufer migrieren und das Flag entfernen.

Enterprise-Java-Einordnung

Aus approve(claim, true) und approve(claim, false) werden approveAutomatically(claim) und requestManualApproval(claim).

Teststrategie

Für jede neue Methode eigene Vertrags- und Negativtests anlegen; gemeinsame Invarianten zusätzlich als Contract Test sichern.

DocumentDeliveryCommands.java

package com.aydinsude.workbench.catalog;
// Refactoring: Remove Flag Argument
// Command-Methoden: Jede Variante besitzt einen sprechenden Vertrag.
public final class DocumentDeliveryCommands {
  public String sendImmediately(String documentId) { return "sent:" + documentId; }
  public String queueForReview(String documentId) { return "queued:" + documentId; }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

25. Replace Constructor with Factory Function

Sicherer Refactoring-Ablauf

1. Eine benannte Factory Function parallel zum Konstruktor einführen.
2. Invarianten und Standardwerte in die Factory verlagern.
3. Aufrufer schrittweise migrieren.
4. Konstruktorzugriff einschränken, sobald keine externe Nutzung mehr besteht.

Enterprise-Java-Einordnung

Payment.ofCard(...) und Payment.ofBankTransfer(...) erzeugen typisierte Zahlungsvarianten mit geprüften Pflichtdaten.

Teststrategie

Tests prüfen Invarianten, Standardwerte und die Ablehnung unvollständiger Erzeugungsdaten.

PaymentRequestFactory.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Replace Constructor with Factory Function
// Pattern: Factory Method
public record PaymentRequestFactory(String reference, BigDecimal amount, String currency) {
  public static PaymentRequestFactory euroPayment(String reference, BigDecimal amount) {
    if (amount.signum() <= 0) throw new IllegalArgumentException("amount");
    return new PaymentRequestFactory(reference, amount, "EUR");
  }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

26. Replace Function with Command

Sicherer Refactoring-Ablauf

1. Den Funktionsaufruf als unveränderliches Command-Objekt modellieren.
2. Eingaben im Konstruktor oder Record bündeln.
3. Ausführung in execute() oder handle() verschieben.
4. Nebenwirkungen über Ports führen und Ergebnis explizit typisieren.

Enterprise-Java-Einordnung

CloseAccountCommand enthält AccountId, Grund und Antragsteller; ein Handler koordiniert Validierung, Persistenz und Domain Event.

Teststrategie

Tests prüfen erfolgreiche Ausführung, Ablehnung, Idempotenz und Wiederholung mit identischer Command-ID.

ApproveClaimCommand.java

package com.aydinsude.workbench.catalog;
// Refactoring: Replace Function with Command
// Pattern: Command
public final class ApproveClaimCommand {
  private final String claimId; private boolean executed;
  public ApproveClaimCommand(String claimId) { this.claimId=claimId; }
  public Result execute() { if(executed) throw new IllegalStateException("already executed"); executed=true; return new Result(claimId,"APPROVED"); }
  public record Result(String claimId, String status) {}
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

27. Replace Command with Function

Sicherer Refactoring-Ablauf

1. Reinheit und Seiteneffektfreiheit durch Tests belegen.
2. Berechnung als benannte Funktion oder statische Methode anbieten.
3. Aufrufer migrieren.
4. Command-Klasse und unnötige Factory entfernen.

Enterprise-Java-Einordnung

Ein VatCalculationCommand ohne Zustand wird zu calculateVat(Money, TaxRate).

Teststrategie

Property- und Grenzwerttests sichern die reine Berechnung; keine Mock-Interaktionen nötig.

NormalizeCustomerName.java

package com.aydinsude.workbench.catalog;
import java.util.Locale;
// Refactoring: Replace Command with Function
// Zweck: Eine zustandslose Transformation bleibt eine kleine reine Funktion.
public final class NormalizeCustomerName {
  public String normalize(String value) { return value.trim().replaceAll("\\s+"," ").toUpperCase(Locale.ROOT); }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

28. Return Modified Value

Sicherer Refactoring-Ablauf

1. Den tatsächlich erzeugten oder veränderten Wert bestimmen.
2. Die Methode so umstellen, dass sie den neuen Wert zurückgibt.
3. Aufrufer auf explizite Zuweisung migrieren.
4. Verdeckte Mutation reduzieren oder durch unveränderliche Typen ersetzen.

Enterprise-Java-Einordnung

normalize(address) liefert eine neue Address zurück, statt das übergebene DTO still zu verändern.

Teststrategie

Tests vergleichen ursprünglichen und neuen Wert und prüfen, dass die Eingabe unverändert bleibt.

RiskScoreUpdate.java

package com.aydinsude.workbench.catalog;
// Refactoring: Return Modified Value
// Zweck: Der Datenfluss des neuen Risikowerts ist am Aufruf sichtbar.
public final class RiskScoreUpdate {
  public Assessment applyDocumentRisk(Assessment current, int documentRisk) {
    return new Assessment(current.customerId(), current.score() + documentRisk);
  }
  public record Assessment(String customerId, int score) {}
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

29. Replace Inline Code with Function Call

Sicherer Refactoring-Ablauf

1. Verhalten von Inline-Code und Zielfunktion mit Tests vergleichen.
2. Abweichungen sichtbar machen und entscheiden, welche Semantik korrekt ist.
3. Inline-Code durch Funktionsaufruf ersetzen.
4. Duplikate und veraltete Hilfswerte entfernen.

Enterprise-Java-Einordnung

Eine manuelle IBAN-Normalisierung wird durch Iban.normalize(raw) ersetzt.

Teststrategie

Differentialtests vergleichen bisherige Inline-Logik und zentrale Funktion für repräsentative Datensätze.

PremiumCustomerRule.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Replace Inline Code with Function Call
// Specification-artige Regel: Die fachliche Aussage besitzt einen Namen.
public final class PremiumCustomerRule {
  public boolean isPremium(Customer customer) { return customer.orders() >= 10 && customer.revenue().compareTo(new BigDecimal("5000")) >= 0; }
  public record Customer(int orders, BigDecimal revenue) {}
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

30. Remove Setting Method

Sicherer Refactoring-Ablauf

1. Schreibzugriffe und Lebenszyklus des Feldes analysieren.
2. Pflichtwert in Konstruktor oder Factory aufnehmen.
3. Fachliche Änderungen durch benannte Operationen modellieren.
4. Setter entfernen und Feld möglichst final machen.

Enterprise-Java-Einordnung

Eine Order erhält currency im Konstruktor; Statusänderungen laufen ausschließlich über geprüfte Domain-Operationen.

Teststrategie

Tests prüfen, dass ungültige Zwischenzustände nicht erzeugbar sind und erlaubte Übergänge weiterhin funktionieren.

ImmutableContractNumber.java

package com.aydinsude.workbench.catalog;
// Refactoring: Remove Setting Method
// Value Object: Vertragsnummer ist nach Erzeugung unveränderlich.
public record ImmutableContractNumber(String value) {
  public ImmutableContractNumber { if(value==null || value.isBlank()) throw new IllegalArgumentException("value"); }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

31. Move Function

Sicherer Refactoring-Ablauf

1. Abhängigkeiten der Methode messen und Zielklasse bestimmen.
2. Methode zunächst im Ziel duplizieren und durch Tests vergleichen.
3. Aufrufer delegieren lassen.
4. Alte Implementierung entfernen und Sichtbarkeiten verkleinern.

Enterprise-Java-Einordnung

discountFor(customer) wandert aus OrderService in CustomerPricingPolicy oder Customer, abhängig von der fachlichen Invariante.

Teststrategie

Vorher-/Nachher-Contract-Tests und Architekturtests sichern Verhalten sowie erlaubte Paketabhängigkeiten.

CustomerRiskPolicy.java

package com.aydinsude.workbench.catalog;
// Refactoring: Move Function
// Zweck: Die Risikoberechnung liegt beim fachlichen Profil statt in einem fremden Service.
public final class CustomerRiskPolicy {
  public Risk assess(CustomerProfile profile) { return profile.risk(); }
  public record CustomerProfile(int overdueInvoices, boolean politicallyExposed) {
    public Risk risk() { return politicallyExposed || overdueInvoices > 2 ? Risk.HIGH : Risk.NORMAL; }
  }
  public enum Risk { NORMAL, HIGH }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

32. Move Field

Sicherer Refactoring-Ablauf

1. Nutzung und Eigentümerschaft klären.
2. Feld im Zieltyp einführen und synchron halten.
3. Leser und Schreiber schrittweise migrieren.
4. Altes Feld entfernen und Persistenzmapping anpassen.

Enterprise-Java-Einordnung

creditLimit wandert aus CustomerProfile in CreditAccount, weil dort Freigaben und Ausschöpfung verwaltet werden.

Teststrategie

Tests prüfen Datenmigration, Serialisierung und alle Invarianten am neuen Eigentümer.

ContractRenewalDate.java

package com.aydinsude.workbench.catalog;
import java.time.LocalDate;
// Refactoring: Move Field
// Zweck: Das Verlängerungsdatum gehört zum Vertragszeitraum.
public record ContractRenewalDate(String contractId, Term term) {
  public record Term(LocalDate startsOn, LocalDate renewsOn) {
    public boolean renewalDue(LocalDate today) { return !renewsOn.isAfter(today); }
  }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

33. Move Statements into Function

Sicherer Refactoring-Ablauf

1. Gemeinsame Statements und ihre Reihenfolge sichern.
2. Seiteneffekte und Fehlerfälle analysieren.
3. Statements in die Funktion verschieben.
4. Aufrufstellen vereinfachen und Duplikate entfernen.

Enterprise-Java-Einordnung

Eine normalize-and-validate-Sequenz wird Bestandteil von registerCustomer(...), weil jede Registrierung sie zwingend benötigt.

Teststrategie

Tests prüfen, dass alle bisherigen Aufrufvarianten weiterhin normalisiert und validiert werden.

InvoiceDispatchPreparation.java

package com.aydinsude.workbench.catalog;
// Refactoring: Move Statements into Function
// Template Method: Vorbereitung und Versand bilden einen stabilen Ablauf.
public final class InvoiceDispatchPreparation {
  public String dispatch(String invoiceId) { return prepare(invoiceId) + ":sent"; }
  private String prepare(String invoiceId) { return "validated:" + invoiceId; }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

34. Move Statements to Callers

Sicherer Refactoring-Ablauf

1. Gemeinsamen Kern und aufruferspezifische Schritte trennen.
2. Speziallogik an betroffene Aufrufer verschieben.
3. Gemeinsame Funktion neu benennen oder vereinfachen.
4. Duplikate nur dort extrahieren, wo ein echter Begriff besteht.

Enterprise-Java-Einordnung

generateInvoice() erzeugt nur das Dokument; Versand und Archivierung werden von den jeweiligen Anwendungsfällen orchestriert.

Teststrategie

Contract-Tests sichern den Kern; spezifische Aufrufertests prüfen Versand und Archivierung getrennt.

CustomerNotificationTemplate.java

package com.aydinsude.workbench.catalog;
// Refactoring: Move Statements to Callers
// Strategy am Aufrufer: Der gemeinsame Text bleibt zentral, der Kanal ergänzt seine Variante.
public final class CustomerNotificationTemplate {
  public String baseMessage(String customerId) { return "customer:" + customerId; }
  public String email(String customerId) { return baseMessage(customerId) + ":email-footer"; }
  public String sms(String customerId) { return baseMessage(customerId) + ":sms-short"; }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

35. Replace Type Code with Subclasses

Sicherer Refactoring-Ablauf

1. Varianten und gemeinsame Invarianten erfassen.
2. Eine gemeinsame Abstraktion einführen.
3. Je Variante Unterklasse oder versiegelten Typ anlegen.
4. Erzeugung zentralisieren und Verzweigungen schrittweise durch Polymorphie ersetzen.

Enterprise-Java-Einordnung

PaymentMethod wird als versiegelte Hierarchie CardPayment, BankTransfer und InvoicePayment modelliert.

Teststrategie

Contract-Tests gelten für alle Varianten; zusätzliche Tests prüfen variantenspezifische Invarianten.

PaymentMethodHierarchy.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Replace Type Code with Subclasses
// Pattern: Polymorphism
public sealed interface PaymentMethodHierarchy permits PaymentMethodHierarchy.Card, PaymentMethodHierarchy.Transfer {
  BigDecimal fee(BigDecimal amount);
  record Card() implements PaymentMethodHierarchy { public BigDecimal fee(BigDecimal amount){ return amount.multiply(new BigDecimal("0.02")); } }
  record Transfer() implements PaymentMethodHierarchy { public BigDecimal fee(BigDecimal amount){ return new BigDecimal("0.50"); } }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

36. Remove Subclass

Sicherer Refactoring-Ablauf

1. Öffentliche Unterschiede und Instanziierungen erfassen.
2. Unterscheidungsdaten in die Oberklasse oder ein Value Object überführen.
3. Factory und Aufrufer migrieren.
4. Unterklasse entfernen und Verträge vereinfachen.

Enterprise-Java-Einordnung

DomesticCustomer und InternationalCustomer werden zu Customer mit einer geprüften MarketRegion, sofern das Verhalten identisch geworden ist.

Teststrategie

Tests vergleichen Serialisierung, Factory-Auswahl und alle bisherigen Varianten.

UnifiedCustomerAccount.java

package com.aydinsude.workbench.catalog;
// Refactoring: Remove Subclass
// Value Object: Der Kontotyp ist Datenwert statt leerer Unterklasse.
public record UnifiedCustomerAccount(String id, AccountType type) {
  public boolean business() { return type == AccountType.BUSINESS; }
  public enum AccountType { PRIVATE, BUSINESS }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

37. Extract Superclass

Sicherer Refactoring-Ablauf

1. Gemeinsamen Vertrag und echte Ist-ein-Beziehung prüfen.
2. Identische Methoden schrittweise hochziehen.
3. Gemeinsame Felder kapseln und Konstruktion vereinheitlichen.
4. Substituierbarkeit mit Contract-Tests sichern.

Enterprise-Java-Einordnung

EmailNotification und SmsNotification können eine abstrakte Notification mit gemeinsamer Empfänger- und Auditlogik erhalten, sofern ihre Verträge übereinstimmen.

Teststrategie

Contract-Tests prüfen die Oberklasseninvarianten für jede Unterklasse.

AuditedOperation.java

package com.aydinsude.workbench.catalog;
import java.time.Instant;
// Refactoring: Extract Superclass
// Template Method: Gemeinsames Audit-Gerüst, fachliche Aktion bleibt abstrakt.
public abstract class AuditedOperation {
  public final Result execute(String actor) { return new Result(actor,Instant.EPOCH,perform()); }
  protected abstract String perform();
  public record Result(String actor, Instant at, String value) {}
  public static final class CloseOrder extends AuditedOperation { protected String perform(){ return "ORDER_CLOSED"; } }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

38. Collapse Hierarchy

Sicherer Refactoring-Ablauf

1. Substituierbarkeit und Nutzung beider Typen prüfen.
2. Felder und Methoden in den verbleibenden Typ verschieben.
3. Factories, Serialisierung und Persistenz migrieren.
4. Überflüssigen Typ entfernen und API-Kompatibilität behandeln.

Enterprise-Java-Einordnung

BaseContract und Contract werden zusammengeführt, nachdem keine alternative Unterklasse und kein abweichendes Verhalten mehr existiert.

Teststrategie

Regressionstests sichern JSON-, Datenbank- und API-Kompatibilität.

CollapsedApprovalRule.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Collapse Hierarchy
// Zweck: Eine unnötige Vererbungsebene wird entfernt.
public final class CollapsedApprovalRule {
  private final BigDecimal limit;
  public CollapsedApprovalRule(BigDecimal limit){ this.limit=limit; }
  public boolean approves(BigDecimal amount){ return amount.compareTo(limit) <= 0; }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

39. Replace Subclass with Delegate

Sicherer Refactoring-Ablauf

1. Variantenspezifisches Verhalten in ein Delegate-Interface extrahieren.
2. Delegate in der bisherigen Basisklasse halten.
3. Unterklassen schrittweise durch konfigurierte Instanzen ersetzen.
4. Hierarchie entfernen und Erzeugung zentralisieren.

Enterprise-Java-Einordnung

PremiumOrder-Unterklasse wird durch PricingPolicy und FulfillmentPolicy ersetzt, die unabhängig kombinierbar sind.

Teststrategie

Contract-Tests prüfen alle Delegate-Implementierungen und ausgewählte Kombinationen.

DeliveryServiceDelegate.java

package com.aydinsude.workbench.catalog;
// Refactoring: Replace Subclass with Delegate
// Pattern: Strategy/Delegation
public final class DeliveryServiceDelegate {
  private final RoutePolicy policy;
  public DeliveryServiceDelegate(RoutePolicy policy){ this.policy=policy; }
  public String route(String destination){ return policy.route(destination); }
  public interface RoutePolicy { String route(String destination); }
  public static final class Express implements RoutePolicy { public String route(String d){ return "EXPRESS:"+d; } }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

40. Replace Superclass with Delegate

Sicherer Refactoring-Ablauf

1. Tatsächlich benötigte Funktionen der Oberklasse erfassen.
2. Ein fokussiertes Delegate-Feld und eine schmale Schnittstelle einführen.
3. Aufrufe auf Delegation umstellen.
4. Vererbung entfernen und nicht passende API verschwinden lassen.

Enterprise-Java-Einordnung

CustomerReport erbt nicht mehr von ArrayList, sondern besitzt eine List<ReportRow> und bietet nur fachliche Operationen an.

Teststrategie

Tests prüfen, dass nur erlaubte Operationen verfügbar sind und Delegatwechsel dasselbe Fachverhalten liefern.

CustomerScoringDelegate.java

package com.aydinsude.workbench.catalog;
// Refactoring: Replace Superclass with Delegate
// Pattern: Delegation over inheritance
public final class CustomerScoringDelegate {
  private final ScoreNormalizer normalizer;
  public CustomerScoringDelegate(ScoreNormalizer normalizer){ this.normalizer=normalizer; }
  public int score(int raw){ return normalizer.normalize(raw); }
  public static final class ScoreNormalizer { public int normalize(int raw){ return Math.max(0,Math.min(100,raw)); } }
}

Deutschsprachige fachliche Grundlagen

Die Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das vorhandene Java-Beispiel übertragen. Die Quellen dienen als fachliche Grundlage; der Text ist keine Übersetzung eines englischen Eintrags.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

41. Replace Primitive with Object

Sicherer Refactoring-Ablauf

1. Money, EmailAddress oder CustomerNumber als unveränderliches Value Object einführen; zunächst Konstruktion absichern, dann Signaturen schrittweise umstellen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Replace Primitive with Object nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

MoneyValue.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
import java.util.Objects;
// Refactoring: Replace Primitive with Object
// Value Object: Money bündelt Betrag, Währung und fachliche Invarianten.
public record MoneyValue(BigDecimal amount, String currency) {
  public MoneyValue {
    Objects.requireNonNull(amount); Objects.requireNonNull(currency);
    if (currency.isBlank()) throw new IllegalArgumentException("currency");
  }
  public MoneyValue add(MoneyValue other) {
    if (!currency.equals(other.currency)) throw new IllegalArgumentException("currency mismatch");
    return new MoneyValue(amount.add(other.amount), currency);
  }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class MoneyValueTest { @Test void primitive_becomes_value_object(){ var sum=new MoneyValue(new BigDecimal("10.00"),"EUR").add(new MoneyValue(new BigDecimal("2.50"),"EUR")); assertEquals(new BigDecimal("12.50"),sum.amount()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

42. Replace Temp with Query

Sicherer Refactoring-Ablauf

1. Berechnung in eine kleine Query extrahieren, Tests sichern, temporäre Variable ersetzen und erst danach weitere Methoden abtrennen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Replace Temp with Query nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

OrderNetAmountQuery.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Replace Temp with Query
// Query Object: Die Berechnung ist benannt, wiederverwendbar und ohne Seiteneffekt.
public final class OrderNetAmountQuery {
  public BigDecimal net(BigDecimal gross, BigDecimal discount) { return gross.subtract(discount); }
  public boolean requiresApproval(BigDecimal gross, BigDecimal discount) { return net(gross,discount).compareTo(new BigDecimal("1000")) > 0; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class OrderNetAmountQueryTest { @Test void temp_is_query(){ assertTrue(new OrderNetAmountQuery().requiresApproval(new BigDecimal("1200"),new BigDecimal("100"))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

43. Encapsulate Record

Sicherer Refactoring-Ablauf

1. Zunächst lesenden Wrapper einführen, dann Erzeugung zentralisieren, Schreibzugriffe in Methoden überführen und rohe Struktur aus der API entfernen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Encapsulate Record nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

CustomerRecord.java

package com.aydinsude.workbench.catalog;
import java.util.Map;
// Refactoring: Encapsulate Record
// Facade: Benannte Fachzugriffe verbergen die untypisierte Legacy-Struktur.
public final class CustomerRecord {
  private final Map<String,String> data;
  public CustomerRecord(Map<String,String> data){ this.data=Map.copyOf(data); }
  public String customerId(){ return required("customerId"); }
  public String email(){ return required("email"); }
  private String required(String key){ var value=data.get(key); if(value==null||value.isBlank()) throw new IllegalStateException(key); return value; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.util.Map; import org.junit.jupiter.api.Test;
class CustomerRecordTest { @Test void record_is_encapsulated(){ var c=new CustomerRecord(Map.of("customerId","C1","email","a@example.test")); assertEquals("C1",c.customerId()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

44. Encapsulate Collection

Sicherer Refactoring-Ablauf

1. Defensive Sicht zurückgeben, fachliche add/remove-Methoden einführen, Aufrufer migrieren und direkte Collection-Mutation sperren.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Encapsulate Collection nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

OrderLineCollection.java

package com.aydinsude.workbench.catalog;
import java.util.ArrayList; import java.util.List;
// Refactoring: Encapsulate Collection
// Aggregate: Änderungen an Positionen laufen ausschließlich über die Aggregate-Grenze.
public final class OrderLineCollection {
  private final List<String> lines=new ArrayList<>();
  public void add(String sku){ if(sku==null||sku.isBlank()) throw new IllegalArgumentException("sku"); lines.add(sku); }
  public List<String> lines(){ return List.copyOf(lines); }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class OrderLineCollectionTest { @Test void collection_is_protected(){ var o=new OrderLineCollection(); o.add("SKU-1"); assertThrows(UnsupportedOperationException.class,()->o.lines().add("SKU-2")); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

45. Replace Magic Literal with Symbolic Constant

Sicherer Refactoring-Ablauf

1. Bedeutung klären, Vorkommen fachlich unterscheiden, Konstante nahe am Besitzer definieren und Tests für Grenzwerte ergänzen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Replace Magic Literal with Symbolic Constant nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

ApprovalThreshold.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Replace Magic Literal with Symbolic Constant
// Policy: Der Schwellenwert besitzt einen fachlichen Namen und eine zentrale Heimat.
public final class ApprovalThreshold {
  public static final BigDecimal MANUAL_APPROVAL_LIMIT=new BigDecimal("10000.00");
  public boolean manualApprovalRequired(BigDecimal amount){ return amount.compareTo(MANUAL_APPROVAL_LIMIT)>0; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class ApprovalThresholdTest { @Test void symbolic_constant_explains_rule(){ assertTrue(new ApprovalThreshold().manualApprovalRequired(new BigDecimal("10000.01"))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

46. Introduce Assertion

Sicherer Refactoring-Ablauf

1. Invariante identifizieren, Assertion an der Entstehungs- oder Nutzungskante platzieren und fachliche Eingabefehler weiterhin regulär behandeln.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Introduce Assertion nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

SettlementInvariant.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Introduce Assertion
// Invariant: Settlement darf nur für positive, bereits abgeglichene Beträge entstehen.
public final class SettlementInvariant {
  public String settle(BigDecimal amount, boolean reconciled){
    if(amount.signum()<=0) throw new IllegalStateException("amount must be positive");
    if(!reconciled) throw new IllegalStateException("payment must be reconciled");
    return "SETTLED:"+amount;
  }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class SettlementInvariantTest { @Test void invalid_state_fails_near_source(){ assertThrows(IllegalStateException.class,()->new SettlementInvariant().settle(BigDecimal.TEN,false)); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

47. Replace Nested Conditional with Guard Clauses

Sicherer Refactoring-Ablauf

1. Bedingungen einzeln charakterisieren, negierte Logik verständlich benennen, Guard Clauses schrittweise einführen und Verhalten testen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Replace Nested Conditional with Guard Clauses nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

ClaimEligibilityGuards.java

package com.aydinsude.workbench.catalog;
// Refactoring: Replace Nested Conditional with Guard Clauses
// Specification-artige Guards: Jeder Ablehnungsgrund ist früh und separat sichtbar.
public final class ClaimEligibilityGuards {
  public String decide(boolean activePolicy, boolean completeDocuments, int amount){
    if(!activePolicy) return "REJECTED_POLICY";
    if(!completeDocuments) return "REJECTED_DOCUMENTS";
    if(amount<=0) return "REJECTED_AMOUNT";
    return "ACCEPTED";
  }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class ClaimEligibilityGuardsTest { @Test void guards_keep_happy_path_flat(){ assertEquals("ACCEPTED",new ClaimEligibilityGuards().decide(true,true,100)); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

48. Replace Conditional with Polymorphism

Sicherer Refactoring-Ablauf

1. Variationsachse bestimmen, Interface extrahieren, eine Variante nach der anderen verschieben und Auswahl in Factory oder Registry isolieren.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Replace Conditional with Polymorphism nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

DeliveryPricingPolymorphism.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Replace Conditional with Polymorphism
// Design Pattern: Strategy - Versandpreise sind austauschbare Varianten.
public final class DeliveryPricingPolymorphism {
  public BigDecimal price(DeliveryPolicy policy, BigDecimal base){ return policy.price(base); }
  public sealed interface DeliveryPolicy permits Standard, Express { BigDecimal price(BigDecimal base); }
  public record Standard() implements DeliveryPolicy { public BigDecimal price(BigDecimal base){ return base.add(new BigDecimal("4.90")); } }
  public record Express() implements DeliveryPolicy { public BigDecimal price(BigDecimal base){ return base.add(new BigDecimal("14.90")); } }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class DeliveryPricingPolymorphismTest { @Test void conditional_becomes_strategy(){ assertEquals(new BigDecimal("24.90"),new DeliveryPricingPolymorphism().price(new DeliveryPricingPolymorphism.Express(),new BigDecimal("10.00"))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

49. Introduce Special Case

Sicherer Refactoring-Ablauf

1. Gemeinsame Sonderfalllogik sammeln, passendes Objekt einführen, Erzeugung zentralisieren und Prüfungen schrittweise entfernen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Introduce Special Case nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

CustomerContactSpecialCase.java

package com.aydinsude.workbench.catalog;
// Refactoring: Introduce Special Case
// Design Pattern: Null Object - anonyme Kunden besitzen explizites Standardverhalten.
public sealed interface CustomerContactSpecialCase permits CustomerContactSpecialCase.Known, CustomerContactSpecialCase.Anonymous {
  String displayName(); boolean contactable();
  record Known(String displayName, String email) implements CustomerContactSpecialCase { public boolean contactable(){ return email!=null&&!email.isBlank(); } }
  record Anonymous() implements CustomerContactSpecialCase { public String displayName(){ return "Anonymous"; } public boolean contactable(){ return false; } }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class CustomerContactSpecialCaseTest { @Test void special_case_removes_null_checks(){ CustomerContactSpecialCase c=new CustomerContactSpecialCase.Anonymous(); assertEquals("Anonymous",c.displayName()); assertFalse(c.contactable()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

50. Replace Control Flag with Break

Sicherer Refactoring-Ablauf

1. Flag-Verwendungen analysieren, einfachen Abbruch ersetzen, komplexe Schleife gegebenenfalls in eine benannte Suchfunktion extrahieren.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Replace Control Flag with Break nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

FraudSignalSearch.java

package com.aydinsude.workbench.catalog;
import java.util.List;
// Refactoring: Replace Control Flag with Break
// Zweck: Der Abbruch ist direkt am fachlichen Treffer sichtbar.
public final class FraudSignalSearch {
  public String firstBlocked(List<String> signals){
    for(String signal:signals){ if(signal.startsWith("BLOCK:")) return signal.substring(6); }
    return "NONE";
  }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.util.List; import org.junit.jupiter.api.Test;
class FraudSignalSearchTest { @Test void control_flag_is_removed(){ assertEquals("device",new FraudSignalSearch().firstBlocked(List.of("WARN:ip","BLOCK:device","BLOCK:account"))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

51. Extract Class

Sicherer Refactoring-Ablauf

1. Methoden- und Feldcluster identifizieren, neue Klasse einführen, delegieren, Aufrufer migrieren und Schnittstelle anschließend verengen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Extract Class nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

CustomerCreditProfile.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Extract Class
// Design Pattern: Value Object - Kreditdaten und Invarianten bilden eine eigene Fachgrenze.
public record CustomerCreditProfile(BigDecimal limit, BigDecimal exposure) {
  public CustomerCreditProfile { if(limit.signum()<0||exposure.signum()<0) throw new IllegalArgumentException("negative credit values"); }
  public BigDecimal available(){ return limit.subtract(exposure); }
  public boolean canReserve(BigDecimal amount){ return amount.signum()>0 && available().compareTo(amount)>=0; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class CustomerCreditProfileTest { @Test void extracted_class_owns_credit_rule(){ assertTrue(new CustomerCreditProfile(new BigDecimal("1000"),new BigDecimal("250")).canReserve(new BigDecimal("700"))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

52. Inline Class

Sicherer Refactoring-Ablauf

1. Öffentliche Nutzung prüfen, Verhalten und Daten in Besitzer verschieben, Aufrufer umstellen und überflüssigen Typ entfernen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Inline Class nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

ShippingLabel.java

package com.aydinsude.workbench.catalog;
// Refactoring: Inline Class
// Value Object: Die kleine Adresshülle ist direkt Teil des Versandetiketts.
public record ShippingLabel(String recipient, String street, String city) {
  public ShippingLabel { if(recipient.isBlank()||street.isBlank()||city.isBlank()) throw new IllegalArgumentException("complete address required"); }
  public String printable(){ return recipient+" | "+street+" | "+city; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class ShippingLabelTest { @Test void tiny_class_is_inlined(){ assertEquals("Aydin | Main 1 | Vienna",new ShippingLabel("Aydin","Main 1","Vienna").printable()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

53. Hide Delegate

Sicherer Refactoring-Ablauf

1. Häufige Navigation identifizieren, fachlich benannte Methode am passenden Besitzer ergänzen und Clients schrittweise umstellen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Hide Delegate nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

OrderCustomerFacade.java

package com.aydinsude.workbench.catalog;
// Refactoring: Hide Delegate
// Facade: Order verbirgt die interne Customer-Contact-Kette.
public final class OrderCustomerFacade {
  private final Customer customer;
  public OrderCustomerFacade(Customer customer){ this.customer=customer; }
  public String customerEmail(){ return customer.contact().email(); }
  public record Customer(Contact contact) {}
  public record Contact(String email) { public Contact { if(email==null||email.isBlank()) throw new IllegalArgumentException("email"); } }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class OrderCustomerFacadeTest { @Test void delegate_chain_is_hidden(){ var o=new OrderCustomerFacade(new OrderCustomerFacade.Customer(new OrderCustomerFacade.Contact("a@example.test"))); assertEquals("a@example.test",o.customerEmail()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

54. Remove Middle Man

Sicherer Refactoring-Ablauf

1. Weiterleitungen kategorisieren, fachlich wertvolle behalten, triviale Clients direkt anbinden und alte Methoden deprecaten.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Remove Middle Man nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

PaymentGatewayAccess.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Remove Middle Man
// Port and Adapter: Der Use Case arbeitet direkt gegen den stabilen PaymentPort.
public final class PaymentGatewayAccess {
  private final PaymentPort port;
  public PaymentGatewayAccess(PaymentPort port){ this.port=port; }
  public String charge(String orderId, BigDecimal amount){ return port.charge(orderId,amount); }
  public interface PaymentPort { String charge(String orderId, BigDecimal amount); }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class PaymentGatewayAccessTest { @Test void meaningless_middle_man_is_removed(){ var u=new PaymentGatewayAccess((id,a)->"PAID:"+id+":"+a); assertEquals("PAID:O1:12.50",u.charge("O1",new BigDecimal("12.50"))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

55. Substitute Algorithm

Sicherer Refactoring-Ablauf

1. Verhaltensbaseline und Randfälle sichern, neuen Algorithmus parallel implementieren, Ergebnisse vergleichen und kontrolliert umschalten.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Substitute Algorithm nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

PrioritySortAlgorithm.java

package com.aydinsude.workbench.catalog;
import java.util.Comparator; import java.util.List;
// Refactoring: Substitute Algorithm
// Strategy: Comparator beschreibt die Sortierregel explizit.
public final class PrioritySortAlgorithm {
  public List<Ticket> sort(List<Ticket> tickets){ return tickets.stream().sorted(Comparator.comparingInt(Ticket::priority).reversed().thenComparing(Ticket::id)).toList(); }
  public record Ticket(String id,int priority) {}
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.util.List; import org.junit.jupiter.api.Test;
class PrioritySortAlgorithmTest { @Test void standard_algorithm_is_clear(){ var s=new PrioritySortAlgorithm(); assertEquals(List.of("B","A"),s.sort(List.of(new PrioritySortAlgorithm.Ticket("A",1),new PrioritySortAlgorithm.Ticket("B",2))).stream().map(PrioritySortAlgorithm.Ticket::id).toList()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

56. Decompose Conditional

Sicherer Refactoring-Ablauf

1. Bedingung benennen, then/else-Blöcke extrahieren, gemeinsame Datenübergabe reduzieren und anschließend weitere Pattern prüfen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Decompose Conditional nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

ContractPricingDecision.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal; import java.time.LocalDate;
// Refactoring: Decompose Conditional
// Policy: Benannte Teilentscheidungen machen die Preisregel lesbar.
public final class ContractPricingDecision {
  public BigDecimal price(LocalDate today, LocalDate validUntil, boolean premium, BigDecimal base){
    if(isExpired(today,validUntil)) return BigDecimal.ZERO;
    return premiumPrice(premium,base);
  }
  private boolean isExpired(LocalDate today, LocalDate validUntil){ return today.isAfter(validUntil); }
  private BigDecimal premiumPrice(boolean premium, BigDecimal base){ return premium?base.multiply(new BigDecimal("0.90")):base; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import java.time.LocalDate; import org.junit.jupiter.api.Test;
class ContractPricingDecisionTest { @Test void conditional_parts_are_named(){ assertEquals(new BigDecimal("90.00"),new ContractPricingDecision().price(LocalDate.of(2026,1,1),LocalDate.of(2026,12,31),true,new BigDecimal("100.00"))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

57. Consolidate Conditional Expression

Sicherer Refactoring-Ablauf

1. Gleiches Ergebnis verifizieren, Bedingungen kombinieren, Ausdruck benennen und Wahrheitstabelle testen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Consolidate Conditional Expression nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

EligibilityRules.java

package com.aydinsude.workbench.catalog;
// Refactoring: Consolidate Conditional Expression
// Specification: Die gesamte Zulässigkeit besitzt einen Namen und eine Testgrenze.
public final class EligibilityRules {
  public boolean eligible(int age, boolean activeAccount, boolean sanctionsHit){ return hasMinimumAge(age)&&activeAccount&&!sanctionsHit; }
  private boolean hasMinimumAge(int age){ return age>=18; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class EligibilityRulesTest { @Test void conditions_are_consolidated(){ assertTrue(new EligibilityRules().eligible(30,true,false)); assertFalse(new EligibilityRules().eligible(17,true,false)); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

58. Consolidate Duplicate Conditional Fragments

Sicherer Refactoring-Ablauf

1. Duplikat auf Seiteneffekte prüfen, gemeinsame Reihenfolge sichern, Fragment verschieben und beide Pfade testen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Consolidate Duplicate Conditional Fragments nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

NotificationDispatch.java

package com.aydinsude.workbench.catalog;
// Refactoring: Consolidate Duplicate Conditional Fragments
// Template Method-artiger Ablauf: Varianten unterscheiden nur den Kanal, Abschluss bleibt gemeinsam.
public final class NotificationDispatch {
  public String dispatch(boolean urgent,String message){
    String channel=urgent?"SMS":"EMAIL";
    String sent=channel+":"+message;
    return audit(sent);
  }
  private String audit(String sent){ return "AUDITED:"+sent; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class NotificationDispatchTest { @Test void duplicate_fragments_are_consolidated(){ assertEquals("AUDITED:SMS:alert",new NotificationDispatch().dispatch(true,"alert")); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

59. Replace Error Code with Exception

Sicherer Refactoring-Ablauf

1. Fehlerklassen definieren, Aufrufer einzeln migrieren, Ursache erhalten und API-Vertrag dokumentieren.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Replace Error Code with Exception nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

InventoryReservation.java

package com.aydinsude.workbench.catalog;
// Refactoring: Replace Error Code with Exception
// Domain Exception: Fehlschlag transportiert fachlichen Kontext statt Zahlencode.
public final class InventoryReservation {
  public String reserve(String sku,int requested,int available){
    if(requested<=0) throw new IllegalArgumentException("requested");
    if(available<requested) throw new InsufficientStockException(sku,requested,available);
    return "RESERVED:"+sku+":"+requested;
  }
  public static final class InsufficientStockException extends RuntimeException {
    public InsufficientStockException(String sku,int requested,int available){ super("sku="+sku+", requested="+requested+", available="+available); }
  }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class InventoryReservationTest { @Test void error_code_becomes_exception(){ assertThrows(InventoryReservation.InsufficientStockException.class,()->new InventoryReservation().reserve("S1",5,2)); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

60. Replace Exception with Precheck

Sicherer Refactoring-Ablauf

1. Atomare oder konsistente Precheck-Möglichkeit prüfen, Bedingung extrahieren und Race Conditions berücksichtigen.

Enterprise-Java-Einordnung

In einer Enterprise-Anwendung wird Replace Exception with Precheck nicht isoliert angewendet, sondern an einer klaren fachlichen oder technischen Grenze. Der vorhandene Java-21-Code zeigt eine kleine, kompilierbare Zielstruktur; in Spring oder Jakarta EE bleibt die Fachlogik dabei unabhängig vom Framework.

Teststrategie

Vor der Änderung sichern Characterization Tests das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfall, Grenzwerte und Fehlerpfade; bei öffentlichen APIs kommen Vertrags- oder Integrationstests hinzu.

DocumentLookup.java

package com.aydinsude.workbench.catalog;
import java.util.Map; import java.util.Optional;
// Refactoring: Replace Exception with Precheck
// Repository Query: Erwartbare Abwesenheit wird als Optional modelliert.
public final class DocumentLookup {
  private final Map<String,String> documents;
  public DocumentLookup(Map<String,String> documents){ this.documents=Map.copyOf(documents); }
  public Optional<String> find(String id){ if(id==null||id.isBlank()) return Optional.empty(); return Optional.ofNullable(documents.get(id)); }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.util.Map; import org.junit.jupiter.api.Test;
class DocumentLookupTest { @Test void expected_absence_is_not_exceptional(){ assertTrue(new DocumentLookup(Map.of("D1","content")).find("missing").isEmpty()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Die Quellen dienen als Grundlage; der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Entwurfsmuster

61. Split Variable

Sicherer Refactoring-Ablauf

1. Zuweisungen und Verwendungen gruppieren, für jede Bedeutung einen präzisen Namen einführen, schrittweise ersetzen und anschließend unnötige Mutationen entfernen.

Enterprise-Java-Einordnung

Split Variable wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

PricingCalculation.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Split Variable
// Value Object-orientiert: Jede Rechenstufe besitzt eine eindeutige Bedeutung.
public final class PricingCalculation {
  public BigDecimal total(BigDecimal unitPrice,int quantity,BigDecimal discountRate){
    BigDecimal gross=unitPrice.multiply(BigDecimal.valueOf(quantity));
    BigDecimal discount=gross.multiply(discountRate);
    BigDecimal net=gross.subtract(discount);
    return net;
  }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class PricingCalculationTest { @Test void variables_have_single_meaning(){ assertEquals(new BigDecimal("180.00"),new PricingCalculation().total(new BigDecimal("100.00"),2,new BigDecimal("0.10"))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

62. Rename Field

Sicherer Refactoring-Ablauf

1. Verwendungen und Serialisierungsverträge ermitteln, Feld kontrolliert umbenennen, Mapper und Tests anpassen und externe Kompatibilität bewusst sichern.

Enterprise-Java-Einordnung

Rename Field wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

CustomerAccount.java

package com.aydinsude.workbench.catalog;
// Refactoring: Rename Field
// Ubiquitous Language: Der Feldname spiegelt den Fachbegriff wider.
public record CustomerAccount(String accountStatus) {
  public CustomerAccount { if(accountStatus==null||accountStatus.isBlank()) throw new IllegalArgumentException("accountStatus"); }
  public boolean active(){ return "ACTIVE".equals(accountStatus); }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class CustomerAccountTest { @Test void field_name_expresses_domain(){ assertTrue(new CustomerAccount("ACTIVE").active()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

63. Pull Up Method

Sicherer Refactoring-Ablauf

1. Vorbedingungen vergleichen, Unterschiede beseitigen oder parametrisieren, Methode in die Oberklasse verschieben und Unterklassen schrittweise vereinfachen.

Enterprise-Java-Einordnung

Pull Up Method wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

NotificationTemplate.java

package com.aydinsude.workbench.catalog;
// Refactoring: Pull Up Method
// Template Method: Gemeinsame Normalisierung liegt in der Basisklasse.
public abstract class NotificationTemplate {
  public final String render(String message){ return channel()+":"+normalize(message); }
  protected abstract String channel();
  protected String normalize(String message){ return message.trim().replaceAll("\\s+"," "); }
  public static final class Email extends NotificationTemplate { protected String channel(){ return "EMAIL"; } }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class NotificationTemplateTest { @Test void common_method_is_pulled_up(){ assertEquals("EMAIL:hello world",new NotificationTemplate.Email().render(" hello   world ")); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

64. Pull Up Field

Sicherer Refactoring-Ablauf

1. Semantik und Initialisierung vergleichen, Feld in die Oberklasse verschieben, Konstruktoren anpassen und Sichtbarkeit möglichst klein halten.

Enterprise-Java-Einordnung

Pull Up Field wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

AuditedCommand.java

package com.aydinsude.workbench.catalog;
// Refactoring: Pull Up Field
// Command: Gemeinsamer Korrelationskontext wird zentral verwaltet.
public abstract class AuditedCommand {
  private final String correlationId;
  protected AuditedCommand(String correlationId){ if(correlationId==null||correlationId.isBlank()) throw new IllegalArgumentException("correlationId"); this.correlationId=correlationId; }
  public String correlationId(){ return correlationId; }
  public static final class ApproveOrder extends AuditedCommand { public ApproveOrder(String id){ super(id); } }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class AuditedCommandTest { @Test void common_field_is_pulled_up(){ assertEquals("corr-1",new AuditedCommand.ApproveOrder("corr-1").correlationId()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

65. Pull Up Constructor Body

Sicherer Refactoring-Ablauf

1. Gemeinsame Initialisierung identifizieren, geschützten Oberklassenkonstruktor einführen, super-Aufrufe ergänzen und Duplikate entfernen.

Enterprise-Java-Einordnung

Pull Up Constructor Body wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

BaseImportJob.java

package com.aydinsude.workbench.catalog;
// Refactoring: Pull Up Constructor Body
// Template Method: Gemeinsame Initialisierung liegt in der Basisklasse.
public abstract class BaseImportJob {
  private final String source;
  protected BaseImportJob(String source){ if(source==null||source.isBlank()) throw new IllegalArgumentException("source"); this.source=source.trim(); }
  public String source(){ return source; }
  public static final class CsvImportJob extends BaseImportJob { public CsvImportJob(String source){ super(source); } }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class BaseImportJobTest { @Test void constructor_body_is_pulled_up(){ assertEquals("orders.csv",new BaseImportJob.CsvImportJob(" orders.csv ").source()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

66. Push Down Method

Sicherer Refactoring-Ablauf

1. Nutzer der Methode ermitteln, Methode in passende Unterklasse verschieben, Aufrufer auf präzisere Typen umstellen und Oberklassenvertrag verkleinern.

Enterprise-Java-Einordnung

Push Down Method wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

ExportFormat.java

package com.aydinsude.workbench.catalog;
// Refactoring: Push Down Method
// Polymorphism: Variantenspezifisches Verhalten bleibt bei der Variante.
public sealed interface ExportFormat permits CsvExport, PdfExport { String mediaType(); }
final class CsvExport implements ExportFormat { public String mediaType(){ return "text/csv"; } public char delimiter(){ return ';'; } }
final class PdfExport implements ExportFormat { public String mediaType(){ return "application/pdf"; } }

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class ExportFormatTest { @Test void specialized_method_is_pushed_down(){ assertEquals(';',new CsvExport().delimiter()); assertEquals("application/pdf",new PdfExport().mediaType()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

67. Push Down Field

Sicherer Refactoring-Ablauf

1. Verwendungen analysieren, Feld und Initialisierung in die betroffenen Unterklassen verschieben und Oberklassenkonstruktor vereinfachen.

Enterprise-Java-Einordnung

Push Down Field wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

DeliveryOption.java

package com.aydinsude.workbench.catalog;
import java.time.Duration;
// Refactoring: Push Down Field
// Polymorphism: Express-spezifische SLA liegt nur in ExpressDelivery.
public sealed interface DeliveryOption permits StandardDelivery, ExpressDelivery { String code(); }
final class StandardDelivery implements DeliveryOption { public String code(){ return "STANDARD"; } }
record ExpressDelivery(Duration serviceLevel) implements DeliveryOption { public ExpressDelivery { if(serviceLevel.isNegative()||serviceLevel.isZero()) throw new IllegalArgumentException("serviceLevel"); } public String code(){ return "EXPRESS"; } }

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.time.Duration; import org.junit.jupiter.api.Test;
class DeliveryOptionTest { @Test void specialized_field_is_pushed_down(){ assertEquals(Duration.ofHours(4),new ExpressDelivery(Duration.ofHours(4)).serviceLevel()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

68. Replace Delegation with Inheritance

Sicherer Refactoring-Ablauf

1. Liskov-Substitution prüfen, Basisklasse kontrollierbar machen, Delegation schrittweise ersetzen und Verhalten mit Vertragstests absichern.

Enterprise-Java-Einordnung

Replace Delegation with Inheritance wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

CsvReportFormatter.java

package com.aydinsude.workbench.catalog;
// Refactoring: Replace Delegation with Inheritance
// Template Method: CSV-Formatter ist eine echte Spezialisierung des Basisformatters.
public class CsvReportFormatter extends ReportFormatter {
  @Override protected String separator(){ return ";"; }
}
class ReportFormatter {
  protected String separator(){ return ","; }
  public String row(String left,String right){ return left+separator()+right; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class CsvReportFormatterTest { @Test void specialization_uses_inheritance(){ assertEquals("A;B",new CsvReportFormatter().row("A","B")); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

69. Replace Inheritance with Delegation

Sicherer Refactoring-Ablauf

1. Benötigte Fähigkeiten identifizieren, Delegat einführen, Aufrufe schrittweise weiterleiten, öffentlichen Vertrag verkleinern und Vererbung entfernen.

Enterprise-Java-Einordnung

Replace Inheritance with Delegation wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

DiscountedPrice.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Replace Inheritance with Delegation
// Strategy: Preisberechnung wird als kleiner Port delegiert.
public final class DiscountedPrice {
  private final PricePolicy policy;
  public DiscountedPrice(PricePolicy policy){ this.policy=policy; }
  public BigDecimal calculate(BigDecimal base){ return policy.apply(base); }
  public interface PricePolicy { BigDecimal apply(BigDecimal base); }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class DiscountedPriceTest { @Test void delegation_replaces_inheritance(){ var p=new DiscountedPrice(v->v.multiply(new BigDecimal("0.80"))); assertEquals(new BigDecimal("80.0000"),p.calculate(new BigDecimal("100.00"))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

70. Replace Type Code with State/Strategy

Sicherer Refactoring-Ablauf

1. Variationsachse bestimmen, Interface einführen, Varianten schrittweise extrahieren, Auswahl zentralisieren und alte Typcodes aus Verhalten entfernen.

Enterprise-Java-Einordnung

Replace Type Code with State/Strategy wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

PaymentLifecycle.java

package com.aydinsude.workbench.catalog;
// Refactoring: Replace Type Code with State/Strategy
// State Pattern: Jeder Zustand kontrolliert seine erlaubten Übergänge.
public final class PaymentLifecycle {
  private State state=new Pending();
  public void authorize(){ state=state.authorize(); }
  public String status(){ return state.name(); }
  private interface State { State authorize(); String name(); }
  private static final class Pending implements State { public State authorize(){ return new Authorized(); } public String name(){ return "PENDING"; } }
  private static final class Authorized implements State { public State authorize(){ return this; } public String name(){ return "AUTHORIZED"; } }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class PaymentLifecycleTest { @Test void state_replaces_type_code(){ var p=new PaymentLifecycle(); p.authorize(); assertEquals("AUTHORIZED",p.status()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

71. Self Encapsulate Field

Sicherer Refactoring-Ablauf

1. Private Getter/Setter oder fachliche Methoden einführen, interne Zugriffe schrittweise ersetzen und Setter möglichst durch intentionale Operationen begrenzen.

Enterprise-Java-Einordnung

Self Encapsulate Field wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

CustomerBalance.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Self Encapsulate Field
// Encapsulation: Invarianten bleiben an einem kontrollierten Zugriffspunkt.
public final class CustomerBalance {
  private BigDecimal amount = BigDecimal.ZERO;
  public BigDecimal amount(){ return amount; }
  public void changeTo(BigDecimal value){
    if(value==null || value.signum()<0) throw new IllegalArgumentException("amount");
    amount=value;
  }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class CustomerBalanceTest { @Test void field_is_self_encapsulated(){ var b=new CustomerBalance(); b.changeTo(new BigDecimal("25.00")); assertEquals(new BigDecimal("25.00"),b.amount()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

72. Replace Array with Object

Sicherer Refactoring-Ablauf

1. Bedeutung jeder Position dokumentieren, Record oder Klasse einführen, Konvertierung an der Grenze zentralisieren und Aufrufer schrittweise migrieren.

Enterprise-Java-Einordnung

Replace Array with Object wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

ShipmentWindow.java

package com.aydinsude.workbench.catalog;
import java.time.LocalDate;
// Refactoring: Replace Array with Object
// Value Object: Benannte Komponenten ersetzen fragile Indexkonventionen.
public record ShipmentWindow(LocalDate from, LocalDate to) {
  public ShipmentWindow { if(from==null||to==null||to.isBefore(from)) throw new IllegalArgumentException("window"); }
  public long days(){ return java.time.temporal.ChronoUnit.DAYS.between(from,to)+1; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.time.LocalDate; import org.junit.jupiter.api.Test;
class ShipmentWindowTest { @Test void object_replaces_array(){ var w=new ShipmentWindow(LocalDate.of(2026,7,1),LocalDate.of(2026,7,3)); assertEquals(3,w.days()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

73. Change Unidirectional Association to Bidirectional

Sicherer Refactoring-Ablauf

1. Verantwortlichen Besitzer festlegen, Änderungsmethoden auf einer Seite zentralisieren, beide Seiten atomar aktualisieren und Konsistenztests ergänzen.

Enterprise-Java-Einordnung

Change Unidirectional Association to Bidirectional wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

OrderCustomerRelation.java

package com.aydinsude.workbench.catalog;
import java.util.*;
// Refactoring: Change Unidirectional Association to Bidirectional
// Aggregate consistency: Eine Operation hält beide Seiten synchron.
public final class OrderCustomerRelation {
  public static final class Customer { private final List<Order> orders=new ArrayList<>(); public List<Order> orders(){ return List.copyOf(orders); } }
  public static final class Order { private Customer customer; public Customer customer(){ return customer; } }
  public static void assign(Order order, Customer customer){
    if(order.customer!=null) order.customer.orders.remove(order);
    order.customer=Objects.requireNonNull(customer); if(!customer.orders.contains(order)) customer.orders.add(order);
  }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class OrderCustomerRelationTest { @Test void both_sides_stay_consistent(){ var o=new OrderCustomerRelation.Order(); var c=new OrderCustomerRelation.Customer(); OrderCustomerRelation.assign(o,c); assertSame(c,o.customer()); assertEquals(1,c.orders().size()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

74. Change Bidirectional Association to Unidirectional

Sicherer Refactoring-Ablauf

1. Tatsächliche Navigationsnutzung messen, überflüssige Rückreferenz entfernen, Queries oder Repository-Zugriff an der richtigen Grenze ergänzen und Tests anpassen.

Enterprise-Java-Einordnung

Change Bidirectional Association to Unidirectional wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

InvoiceAccountLink.java

package com.aydinsude.workbench.catalog;
// Refactoring: Change Bidirectional Association to Unidirectional
// Simplicity: Nur die fachlich benötigte Richtung bleibt bestehen.
public final class InvoiceAccountLink {
  public record Account(String id) { public Account { if(id==null||id.isBlank()) throw new IllegalArgumentException("id"); } }
  public record Invoice(String number, Account account) { public Invoice { if(number==null||number.isBlank()||account==null) throw new IllegalArgumentException(); } }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class InvoiceAccountLinkTest { @Test void only_required_direction_remains(){ var a=new InvoiceAccountLink.Account("A1"); var i=new InvoiceAccountLink.Invoice("I1",a); assertEquals("A1",i.account().id()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

75. Introduce Foreign Method

Sicherer Refactoring-Ablauf

1. Operation nahe am nutzenden Code als statische oder private Methode einführen, Parameter explizit halten und Duplikate entfernen.

Enterprise-Java-Einordnung

Introduce Foreign Method wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

LegacyDateSupport.java

package com.aydinsude.workbench.catalog;
import java.time.LocalDate;
// Refactoring: Introduce Foreign Method
// Adapter-artige Erweiterung: Fremdtyp bleibt unverändert.
public final class LegacyDateSupport {
  private LegacyDateSupport(){}
  public static LocalDate nextBusinessDay(LocalDate date){
    var next=date.plusDays(1); while(next.getDayOfWeek().getValue()>=6) next=next.plusDays(1); return next;
  }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.time.LocalDate; import org.junit.jupiter.api.Test;
class LegacyDateSupportTest { @Test void foreign_method_extends_external_type(){ assertEquals(LocalDate.of(2026,7,13),LegacyDateSupport.nextBusinessDay(LocalDate.of(2026,7,10))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

76. Introduce Local Extension

Sicherer Refactoring-Ablauf

1. Benötigten Vertrag definieren, Wrapper einführen, Konvertierung zentralisieren und Aufrufer schrittweise auf die lokale Erweiterung umstellen.

Enterprise-Java-Einordnung

Introduce Local Extension wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

MoneyExtension.java

package com.aydinsude.workbench.catalog;
import java.math.*;
// Refactoring: Introduce Local Extension
// Wrapper/Value Object: Lokale Erweiterungen erhalten eine kohärente API.
public record MoneyExtension(BigDecimal value) {
  public MoneyExtension { value=value.setScale(2,RoundingMode.HALF_UP); }
  public MoneyExtension add(MoneyExtension other){ return new MoneyExtension(value.add(other.value)); }
  public boolean positive(){ return value.signum()>0; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class MoneyExtensionTest { @Test void local_extension_groups_operations(){ var sum=new MoneyExtension(new BigDecimal("10")).add(new MoneyExtension(new BigDecimal("2.50"))); assertEquals(new BigDecimal("12.50"),sum.value()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

77. Replace Data Class with Rich Domain Object

Sicherer Refactoring-Ablauf

1. Invarianten und zustandsnahe Regeln identifizieren, fachliche Methoden einführen, Setter entfernen und orchestrierende Services auf Koordination reduzieren.

Enterprise-Java-Einordnung

Replace Data Class with Rich Domain Object wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

ServiceAgreement.java

package com.aydinsude.workbench.catalog;
import java.time.LocalDate;
// Refactoring: Replace Data Class with Rich Domain Object
// Aggregate: Invarianten und Verhalten liegen beim Fachobjekt.
public final class ServiceAgreement {
  private LocalDate validUntil;
  public ServiceAgreement(LocalDate validUntil){ this.validUntil=java.util.Objects.requireNonNull(validUntil); }
  public void extendTo(LocalDate newDate){ if(!newDate.isAfter(validUntil)) throw new IllegalArgumentException("newDate"); validUntil=newDate; }
  public boolean activeOn(LocalDate date){ return !date.isAfter(validUntil); }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.time.LocalDate; import org.junit.jupiter.api.Test;
class ServiceAgreementTest { @Test void rich_object_protects_transition(){ var a=new ServiceAgreement(LocalDate.of(2026,7,31)); a.extendTo(LocalDate.of(2026,8,31)); assertTrue(a.activeOn(LocalDate.of(2026,8,1))); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

78. Replace Boolean with Enum

Sicherer Refactoring-Ablauf

1. Bedeutungen sammeln, Enum einführen, Signaturen und Persistenzmapping migrieren und ungültige Kombinationen mit Tests ausschließen.

Enterprise-Java-Einordnung

Replace Boolean with Enum wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

DeliveryConfirmation.java

package com.aydinsude.workbench.catalog;
// Refactoring: Replace Boolean with Enum
// Type-safe domain model: Benannte Varianten ersetzen mehrdeutige Flags.
public record DeliveryConfirmation(ConfirmationMode mode) {
  public enum ConfirmationMode { NONE, SIGNATURE, ONE_TIME_CODE }
  public boolean requiresCustomerAction(){ return mode!=ConfirmationMode.NONE; }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class DeliveryConfirmationTest { @Test void enum_replaces_boolean(){ assertTrue(new DeliveryConfirmation(DeliveryConfirmation.ConfirmationMode.SIGNATURE).requiresCustomerAction()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

79. Replace Null with Optional Result

Sicherer Refactoring-Ablauf

1. Nur regulär fehlende Ergebnisse umstellen, Rückgabetyp ändern, Aufrufer migrieren und Fehlerfälle weiterhin als Result oder Exception modellieren.

Enterprise-Java-Einordnung

Replace Null with Optional Result wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

CustomerLookupResult.java

package com.aydinsude.workbench.catalog;
import java.util.*;
// Refactoring: Replace Null with Optional Result
// Explicit result contract: Abwesenheit ist Teil der Signatur.
public final class CustomerLookupResult {
  private final Map<String,String> names=Map.of("C1","Ada");
  public Optional<String> findName(String id){ return Optional.ofNullable(names.get(id)); }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test;
class CustomerLookupResultTest { @Test void optional_replaces_null(){ var l=new CustomerLookupResult(); assertEquals("Ada",l.findName("C1").orElseThrow()); assertTrue(l.findName("missing").isEmpty()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

80. Replace Stringly-Typed Map with Typed Record

Sicherer Refactoring-Ablauf

1. Schema und Pflichtfelder bestimmen, Record einführen, Mapper an der Systemgrenze erstellen und interne Aufrufer schrittweise migrieren.

Enterprise-Java-Einordnung

Replace Stringly-Typed Map with Typed Record wird in Enterprise-Java-Anwendungen an einer klaren Fach-, Persistenz- oder Integrationsgrenze eingesetzt. Der vorhandene Java-21-Code zeigt die Zielstruktur ohne Frameworkkopplung; Spring und Jakarta EE bleiben Adapter um die Fachlogik.

Teststrategie

Characterization Tests sichern zunächst das beobachtbare Verhalten. Danach prüfen fokussierte Unit-Tests Normalfälle, Grenzwerte und Fehlerpfade; bei öffentlichen Verträgen kommen Mapper-, Serialisierungs- oder Integrationstests hinzu.

ClaimSubmission.java

package com.aydinsude.workbench.catalog;
import java.math.BigDecimal;
// Refactoring: Replace Stringly-Typed Map with Typed Record
// Value Object: Compiler und Konstruktor sichern das Datenmodell.
public record ClaimSubmission(String claimId, String customerId, BigDecimal amount) {
  public ClaimSubmission {
    if(claimId==null||claimId.isBlank()||customerId==null||customerId.isBlank()||amount==null||amount.signum()<=0) throw new IllegalArgumentException("claim");
  }
}

Java-21-Zielcode.java

package com.aydinsude.workbench.catalog;
import static org.junit.jupiter.api.Assertions.*; import java.math.BigDecimal; import org.junit.jupiter.api.Test;
class ClaimSubmissionTest { @Test void typed_record_replaces_map(){ var c=new ClaimSubmission("CL1","CU1",new BigDecimal("99.00")); assertEquals("CL1",c.claimId()); } }

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul- und Fachquellen redaktionell zusammengeführt und auf das konkrete Java-Beispiel übertragen. Der Text ist keine wörtliche Übersetzung.

• Hochschule Bielefeld: Refactoring
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Refactoring
• Deutschsprachige Grundlagen: Vererbung und Delegation

81. Extract Interface

Sicherer Refactoring-Ablauf

1. Verhalten des bestehenden Aufrufers mit Characterization Tests sichern.
2. Alle tatsächlich verwendeten Provideroperationen und benötigten Datentypen erfassen.
3. Eine kleine, aus Sicht des Verbrauchers benannte Schnittstelle einführen.
4. Die konkrete Providerklasse oder einen Adapter diese Schnittstelle implementieren lassen.
5. Den Aufrufer auf die Schnittstelle umstellen und überflüssige Providerkenntnisse entfernen.

Abgrenzung und Entscheidungshilfe

Extract Interface trennt einen benötigten Vertrag aus einem vorhandenen Typ. Extract Adapter übersetzt zusätzlich zwischen zwei nicht passenden Modellen. Beides kann aufeinander folgen.

Enterprise-Java-Einordnung

Ein Zahlungsanwendungsfall kennt nur PaymentAuthorizationPort. Ein Stripe- oder Bankadapter übersetzt technische Requests und Responses. Die Fachlogik bleibt unabhängig von SDK-Versionen, HTTP-Fehlern und Provider-Metadaten.

Teststrategie

Contract-Tests prüfen den Portvertrag für jede Adapterimplementierung. Unit-Tests des Anwendungsfalls verwenden einen kleinen Fake und prüfen Fachentscheidungen ohne Netzwerkzugriff.

package com.aydinsude.workbench.catalog;
// Refactoring: Extract Interface
// Port Pattern: Der Use Case hängt nur vom benötigten Vertrag ab.
public interface PaymentAuthorizationPort {
  Authorization authorize(String paymentId, long cents);
  record Authorization(String providerReference, boolean approved) {}
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Microsoft Learn (deutsch): Grundlagen der Dependency Injection
• Microsoft Learn (deutsch): Richtlinien für Dependency Injection
• Deutschsprachige Übersicht: Dependency Injection

82. Replace Static Utility with Injected Service

Sicherer Refactoring-Ablauf

1. Statische Aufrufe inventarisieren und reine von zustands- oder umgebungsabhängigen Funktionen trennen.
2. Einen kleinen Service-Vertrag für die veränderliche Fähigkeit definieren.
3. Die vorhandene Logik zunächst unverändert in eine Implementierung verschieben.
4. Den Service über den Konstruktor an die Verbraucher übergeben.
5. Statische Zugriffspunkte nach schrittweiser Migration entfernen.

Abgrenzung und Entscheidungshilfe

Der Kern ist nicht Objektorientierung um jeden Preis, sondern explizite Kontrolle über eine relevante Abhängigkeit.

Enterprise-Java-Einordnung

Steuerberechnung wird als TaxCalculationService injiziert. Regionale Regeln, Stichtage und Rundungsverfahren können separat implementiert und getestet werden, ohne den Bestellservice neu zu verdrahten.

Teststrategie

Unit-Tests injizieren kontrollierte Implementierungen. Contract-Tests sichern gemeinsame Regeln. Ein Integrationstest prüft die produktive Verdrahtung im Composition Root.

package com.aydinsude.workbench.catalog;
import java.math.*;
// Refactoring: Replace Static Utility with Injected Service
// Strategy + Dependency Injection: Steuerregeln sind austauschbar und testbar.
public final class TaxCalculationService {
  public interface TaxPolicy { BigDecimal taxFor(BigDecimal net); }
  private final TaxPolicy policy;
  public TaxCalculationService(TaxPolicy policy){ this.policy=java.util.Objects.requireNonNull(policy); }
  public BigDecimal gross(BigDecimal net){ return net.add(policy.taxFor(net)).setScale(2,RoundingMode.HALF_UP); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Microsoft Learn (deutsch): Grundlagen der Dependency Injection
• Microsoft Learn (deutsch): Richtlinien für Dependency Injection
• Deutschsprachige Übersicht: Dependency Injection

83. Replace Global State with Context Object

Sicherer Refactoring-Ablauf

1. Globale Felder und alle Lese-/Schreibstellen erfassen.
2. Zusammengehörige Werte in einem unveränderlichen Kontexttyp modellieren.
3. Den Kontext zunächst zusätzlich an eine äußere Anwendungsgrenze übergeben.
4. Aufrufer schrittweise von globalem Zugriff auf den Parameter umstellen.
5. Globale Schreiboperationen entfernen und Kontextwechsel explizit modellieren.

Abgrenzung und Entscheidungshilfe

Ein Context Object macht Laufzeitkontext sichtbar. Ein Service Locator liefert dagegen versteckt beliebige Dienste und ist kein Ersatz.

Enterprise-Java-Einordnung

RequestContext enthält TenantId, CorrelationId, Locale und Actor in unveränderlicher Form. Anwendungskommandos erhalten diesen Kontext explizit; Adapter erzeugen ihn an der Systemgrenze.

Teststrategie

Tests erzeugen kleine Kontextinstanzen und prüfen Mandantenisolation sowie unveränderte Weitergabe. Parallelitätstests stellen sicher, dass keine Daten zwischen Requests geteilt werden.

package com.aydinsude.workbench.catalog;
import java.time.Instant;
// Refactoring: Replace Global State with Context Object
// Context Object: Laufzeitdaten sind explizit, unveränderlich und requestgebunden.
public record RequestExecutionContext(String tenantId, String correlationId, Instant startedAt) {
  public RequestExecutionContext {
    if(tenantId==null||tenantId.isBlank()||correlationId==null||correlationId.isBlank()||startedAt==null) throw new IllegalArgumentException("context");
  }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Microsoft Learn (deutsch): Grundlagen der Dependency Injection
• Microsoft Learn (deutsch): Richtlinien für Dependency Injection
• Deutschsprachige Übersicht: Dependency Injection

84. Introduce Dependency Injection

Sicherer Refactoring-Ablauf

1. Direkte Objekterzeugung und versteckte Dienstzugriffe identifizieren.
2. Für jede relevante Fähigkeit einen konkreten oder abstrakten Vertrag bestimmen.
3. Abhängigkeiten als Konstruktorparameter einführen und Felder final machen.
4. Erzeugung in einen Composition Root oder Framework-Konfiguration verschieben.
5. Service-Locator- und Fallback-Pfade entfernen, sobald alle Aufrufer migriert sind.

Abgrenzung und Entscheidungshilfe

Dependency Injection ist die Übergabe von Abhängigkeiten; ein DI-Framework ist nur eine mögliche technische Umsetzung.

Enterprise-Java-Einordnung

OrderApplicationService erhält OrderRepository, PaymentPort, Clock und EventPublisher im Konstruktor. Spring oder CDI verdrahtet die produktiven Adapter außerhalb des Fachmoduls.

Teststrategie

Unit-Tests erstellen den Service direkt mit Fakes. Ein schlanker Container-Smoke-Test prüft, dass die produktive Verdrahtung vollständig und eindeutig ist.

package com.aydinsude.workbench.catalog;
// Refactoring: Introduce Dependency Injection
// Constructor Injection: Abhängigkeiten sind vollständig und unveränderlich.
public final class ShipmentUseCase {
  public interface ShipmentRepository { void save(String shipmentId); }
  public interface NotificationPort { void sent(String shipmentId); }
  private final ShipmentRepository repository; private final NotificationPort notifications;
  public ShipmentUseCase(ShipmentRepository repository, NotificationPort notifications){ this.repository=repository; this.notifications=notifications; }
  public void ship(String id){ repository.save(id); notifications.sent(id); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Microsoft Learn (deutsch): Grundlagen der Dependency Injection
• Microsoft Learn (deutsch): Richtlinien für Dependency Injection
• Deutschsprachige Übersicht: Dependency Injection

85. Replace Service Locator with Constructor Injection

Sicherer Refactoring-Ablauf

1. Alle Locator-Aufrufe pro Klasse erfassen.
2. Pflicht- und optionale Abhängigkeiten unterscheiden.
3. Pflichtabhängigkeiten als Konstruktorparameter einführen.
4. Composition Root oder Framework-Konfiguration auf die neue Signatur umstellen.
5. Locator-Aufrufe entfernen und globale Registrierungen zurückbauen.

Abgrenzung und Entscheidungshilfe

Eine explizit injizierte, fachlich eng begrenzte Registry ist nicht dasselbe wie ein universeller Service Locator.

Enterprise-Java-Einordnung

Ein ExportUseCase erhält DocumentStore und ExporterRegistry direkt. Die Auswahl eines Exporters bleibt dynamisch, aber die Registry ist eine sichtbare Abhängigkeit.

Teststrategie

Konstruktionstests zeigen fehlende Abhängigkeiten sofort. Unit-Tests übergeben Fakes; ein Integrationstest prüft die Containerkonfiguration.

package com.aydinsude.workbench.catalog;
// Refactoring: Replace Service Locator with Constructor Injection
// Explicit Dependencies: Der Vertrag zeigt, was der Use Case wirklich benötigt.
public final class CustomerRegistration {
  public interface CustomerStore { void add(String customerId); }
  public interface WelcomeSender { void send(String customerId); }
  private final CustomerStore store; private final WelcomeSender sender;
  public CustomerRegistration(CustomerStore store, WelcomeSender sender){ this.store=store; this.sender=sender; }
  public void register(String id){ store.add(id); sender.send(id); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Microsoft Learn (deutsch): Grundlagen der Dependency Injection
• Microsoft Learn (deutsch): Richtlinien für Dependency Injection
• Deutschsprachige Übersicht: Dependency Injection

86. Extract Adapter

Sicherer Refactoring-Ablauf

1. Intern benötigte Fähigkeit aus Sicht des Anwendungsfalls als Port formulieren.
2. Fremde Typen und Fehler auf eine Adapterklasse begrenzen.
3. Mapping und Fehlerübersetzung aus den Verbrauchern in den Adapter verschieben.
4. Verbraucher auf den Port umstellen.
5. Adapter mit Contract- und Integrationstests absichern.

Abgrenzung und Entscheidungshilfe

Ein Adapter passt eine Schnittstelle an. Eine Facade vereinfacht ein Subsystem, ohne zwingend inkompatible Modelle zu übersetzen.

Enterprise-Java-Einordnung

BankPaymentAdapter implementiert PaymentPort, übersetzt Money und PaymentRequest in SDK-Objekte und bildet Timeout, Ablehnung und Providerstörung auf typisierte interne Ergebnisse ab.

Teststrategie

Contract-Tests sichern den Port. Mappingtests prüfen Grenzwerte und Fehlerübersetzung. Ein Integrationstest gegen Sandbox oder Stub prüft das echte Protokoll.

package com.aydinsude.workbench.catalog;
// Refactoring: Extract Adapter
// Adapter Pattern: Legacy-Sprache endet an der Integrationsgrenze.
public final class LegacyCustomerAdapter {
  public interface LegacyClient { LegacyCustomer load(String id); }
  public record LegacyCustomer(String number, String activeFlag) {}
  public record Customer(String id, boolean active) {}
  private final LegacyClient client;
  public LegacyCustomerAdapter(LegacyClient client){ this.client=client; }
  public Customer find(String id){ var raw=client.load(id); return new Customer(raw.number(),"Y".equals(raw.activeFlag())); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring

87. Extract Gateway

Sicherer Refactoring-Ablauf

1. Verteilte Zugriffslogik und gemeinsame Operationen sammeln.
2. Eine fachlich benannte Gateway-Schnittstelle definieren.
3. Protokoll- und Mappinglogik in eine Implementierung verschieben.
4. Aufrufer schrittweise umstellen und Duplikate entfernen.
5. Timeout-, Retry- und Observability-Regeln am Gateway zentral testen.

Abgrenzung und Entscheidungshilfe

Gateway bezeichnet den Zugang zu einem externen System; Adapter betont die Übersetzung inkompatibler Schnittstellen. Häufig ist eine Klasse beides.

Enterprise-Java-Einordnung

CustomerRegistryGateway kapselt Abfrage und Aktualisierung eines behördlichen Registers. Der Use Case sieht CustomerStatus statt HTTP-Statuscodes und JSON-Strukturen.

Teststrategie

Gateway-Contract-Tests, Protokolltests mit Stubserver sowie Fehlerklassifikation für Timeout, Nichtgefunden und fachliche Ablehnung.

package com.aydinsude.workbench.catalog;
// Refactoring: Extract Gateway
// Gateway Pattern: Transportdetails bleiben außerhalb der Fachlogik.
public interface FraudScreeningGateway {
  ScreeningResult screen(String customerId, long amountInCents);
  enum ScreeningResult { ACCEPT, REVIEW, REJECT }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring

88. Introduce Repository

Sicherer Refactoring-Ablauf

1. Aggregate und deren Identitätsgrenzen bestimmen.
2. Nur benötigte fachliche Repositoryoperationen definieren.
3. Bestehende SQL-/ORM-Logik in einen Adapter verschieben.
4. Mapping zwischen Persistenz- und Domänenmodell an der Grenze etablieren.
5. Use Cases auf den Repositoryvertrag umstellen.

Abgrenzung und Entscheidungshilfe

DAO ist oft datenquellen- und tabellenorientiert. Repository ist domänenorientiert und spricht in Aggregaten und fachlichen Suchbegriffen.

Enterprise-Java-Einordnung

OrderRepository lädt und speichert Order-Aggregate. Ein JpaOrderRepository übernimmt EntityGraph, Mapping und optimistisches Locking, ohne diese Details an den Use Case weiterzugeben.

Teststrategie

Repository-Contract-Tests laufen gegen In-Memory-Fake und echte Datenbankimplementierung. Integrationstests prüfen Mapping, Nebenläufigkeit und Transaktionsverhalten.

package com.aydinsude.workbench.catalog;
import java.util.*;
// Refactoring: Introduce Repository
// Repository Pattern: Persistenz wird als Aggregat-Sammlung modelliert.
public interface OrderRepositoryBoundary {
  Optional<Order> findById(String id); void save(Order order);
  record Order(String id, String status) { public Order { Objects.requireNonNull(id); Objects.requireNonNull(status); } }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Repository
• Deutschsprachige Übersicht: Unit of Work

89. Introduce Unit of Work

Sicherer Refactoring-Ablauf

1. Geschäftliche Konsistenzgrenze und beteiligte Aggregate bestimmen.
2. Aktuelle Schreiboperationen und Commitpunkte erfassen.
3. Eine Unit-of-Work-Abstraktion oder klaren Transaction Runner einführen.
4. Schreiboperationen innerhalb dieser Grenze ausführen.
5. Commit, Rollback und Fehlerübersetzung zentralisieren.

Abgrenzung und Entscheidungshilfe

Repository kapselt Zugriff auf Aggregate. Unit of Work koordiniert mehrere Änderungen und ihren gemeinsamen Commit.

Enterprise-Java-Einordnung

ApproveClaimUseCase ändert Claim und PaymentInstruction in einer lokalen Transaktion. Ein Outbox-Ereignis wird im selben Commit geschrieben; die externe Auszahlung erfolgt danach.

Teststrategie

Integrationstests erzwingen Fehler zwischen Schreibschritten und prüfen vollständigen Rollback. Nebenläufigkeitstests prüfen Konflikte und Wiederholung.

package com.aydinsude.workbench.catalog;
import java.util.*;
// Refactoring: Introduce Unit of Work
// Unit of Work Pattern: Zusammengehörige Änderungen werden atomar gesammelt.
public final class SettlementUnitOfWork {
  private final List<Runnable> changes=new ArrayList<>();
  public void register(Runnable change){ changes.add(Objects.requireNonNull(change)); }
  public void commit(){ var snapshot=List.copyOf(changes); snapshot.forEach(Runnable::run); changes.clear(); }
  public int pending(){ return changes.size(); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Repository
• Deutschsprachige Übersicht: Unit of Work

90. Introduce Composition Root

Sicherer Refactoring-Ablauf

1. Alle Erzeugungs- und Verdrahtungsstellen erfassen.
2. Abhängigkeiten in Fach- und Anwendungsklassen explizit machen.
3. Produktive Adapter in einer Bootstrap- oder Konfigurationskomponente zusammenführen.
4. Umgebungs- und Variantenentscheidungen ausschließlich dort treffen.
5. Direkte Containerzugriffe und verstreute Fabriken entfernen.

Abgrenzung und Entscheidungshilfe

Composition Root ist ein Ort im Systemdesign. Ein DI-Container ist ein Werkzeug, das dort verwendet werden kann.

Enterprise-Java-Einordnung

Eine Spring-Konfiguration verbindet OrderApplicationService mit JpaOrderRepository, BankPaymentAdapter, SystemClock und OutboxPublisher. Das Domänenmodul kennt Spring nicht.

Teststrategie

Ein Context-Smoke-Test prüft den vollständigen Objektgraphen. Architekturrules verhindern Frameworkabhängigkeiten in Kernmodulen.

package com.aydinsude.workbench.catalog;
// Refactoring: Introduce Composition Root
// Composition Root: Nur hier werden konkrete Adapter mit dem Use Case verdrahtet.
public final class BillingCompositionRoot {
  public interface InvoiceStore { void save(String invoiceId); }
  public static final class BillingUseCase { private final InvoiceStore store; BillingUseCase(InvoiceStore store){ this.store=store; } public void create(String id){ store.save(id); } }
  private BillingCompositionRoot(){}
  public static BillingUseCase create(InvoiceStore store){ return new BillingUseCase(store); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Microsoft Learn (deutsch): Grundlagen der Dependency Injection
• Microsoft Learn (deutsch): Richtlinien für Dependency Injection
• Deutschsprachige Übersicht: Dependency Injection

91. Introduce Value Object

Sicherer Refactoring-Ablauf

1. Einen stabilen fachlichen Begriff mit klaren Invarianten auswählen.
2. Einen unveränderlichen Typ mit validierender Fabrik oder Konstruktor einführen.
3. Zunächst eine Signatur auf den neuen Typ umstellen.
4. Verteilte Validierung und Formatierung in den Typ verschieben.
5. Persistenz- und Transportmapping an den Systemgrenzen ergänzen.

Abgrenzung und Entscheidungshilfe

Value Objects sind nicht bloß DTOs: Sie schützen Invarianten und besitzen fachlich sinnvolles Verhalten.

Enterprise-Java-Einordnung

Money enthält Betrag und Währung, verhindert währungsübergreifende Addition und kapselt Rundungsregeln. EmailAddress normalisiert und validiert Adressen an der Eingangsgrenze.

Teststrategie

Äquivalenz, Hashcode, Grenzwerte, ungültige Konstruktion und fachliche Operationen werden direkt am Typ getestet.

package com.aydinsude.workbench.catalog;
import java.util.Locale;
// Refactoring: Introduce Value Object
// Value Object Pattern: Identität entsteht ausschließlich aus dem fachlichen Wert.
public record EmailAddress(String value) {
  public EmailAddress {
    if (value == null) throw new IllegalArgumentException("email");
    value = value.trim().toLowerCase(Locale.ROOT);
    if (!value.matches("^[^@\\s]+@[^@\\s]+\\.[^@\\s]+$")) throw new IllegalArgumentException("invalid email");
  }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Entwurfsmuster

92. Replace Collection with Domain Collection

Sicherer Refactoring-Ablauf

1. Wiederkehrende Regeln und Operationen der Sammlung erfassen.
2. Einen unveränderlichen oder kontrolliert mutierbaren Sammlungstyp einführen.
3. Erzeugung und Änderungsoperationen mit Invarianten versehen.
4. Signaturen schrittweise auf den Domänentyp umstellen.
5. Direkte Freigabe der internen Collection durch defensive Sichten ersetzen.

Abgrenzung und Entscheidungshilfe

Eine Domain Collection ist ein Fachtyp; ein Repository repräsentiert dagegen eine persistierte Sammlung von Aggregaten.

Enterprise-Java-Einordnung

OrderLines verhindert doppelte Positionsnummern, berechnet Total und liefert nur fachliche Operationen addProduct, removeLine und taxableTotal.

Teststrategie

Invarianten bei Erzeugung und Änderung, defensive Kopien, Aggregationen und Gleichheit der Collection testen.

package com.aydinsude.workbench.catalog;
import java.util.*;
// Refactoring: Replace Collection with Domain Collection
// Domain Collection: Invarianten und Aggregatoperationen liegen bei der Sammlung.
public final class OrderLines {
  public record Line(String productId,int quantity,long unitCents){ public Line { if(productId==null||productId.isBlank()||quantity<1||unitCents<0) throw new IllegalArgumentException("line"); } }
  private final List<Line> lines;
  public OrderLines(List<Line> lines){ if(lines==null||lines.isEmpty()) throw new IllegalArgumentException("empty"); var ids=new HashSet<String>(); for(var l:lines) if(!ids.add(l.productId())) throw new IllegalArgumentException("duplicate"); this.lines=List.copyOf(lines); }
  public long totalCents(){ return lines.stream().mapToLong(l->l.unitCents()*l.quantity()).sum(); }
  public List<Line> asList(){ return lines; }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Entwurfsmuster

93. Extract Domain Service

Sicherer Refactoring-Ablauf

1. Prüfen, ob das Verhalten wirklich in Entity oder Value Object gehört.
2. Benötigte fachliche Eingaben und Ergebnis als klare Typen bestimmen.
3. Eine zustandslose, domänensprachlich benannte Serviceklasse einführen.
4. Logik aus technischen Schichten verschieben.
5. Infrastrukturzugriffe über vorbereitete Werte oder Ports außerhalb halten.

Abgrenzung und Entscheidungshilfe

Domain Service entscheidet fachlich. Application Service koordiniert Ablauf, Transaktion und Ports.

Enterprise-Java-Einordnung

CreditLimitService berechnet aus Kundenrisiko, offenen Forderungen und beantragtem Betrag eine fachliche Kreditentscheidung, ohne Datenbank oder HTTP zu kennen.

Teststrategie

Reine Unit-Tests decken Entscheidungstabellen, Grenzwerte und Symmetrieeigenschaften ab. Keine Frameworkumgebung erforderlich.

package com.aydinsude.workbench.catalog;
// Refactoring: Extract Domain Service
// Domain Service Pattern: Eine fachliche Operation koordiniert mehrere Entities.
public final class TransferDomainService {
  public static final class Account { private long cents; public Account(long cents){ if(cents<0) throw new IllegalArgumentException(); this.cents=cents; } public long balance(){ return cents; } void debit(long amount){ if(amount<=0||amount>cents) throw new IllegalArgumentException("funds"); cents-=amount; } void credit(long amount){ if(amount<=0) throw new IllegalArgumentException("amount"); cents+=amount; } }
  public void transfer(Account source,Account target,long cents){ if(source==target) throw new IllegalArgumentException("same account"); source.debit(cents); target.credit(cents); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Entwurfsmuster

94. Extract Policy Object

Sicherer Refactoring-Ablauf

1. Die fachliche Entscheidung und ihre Einflussgrößen isolieren.
2. Einen benannten Eingabekontext und typisiertes Ergebnis definieren.
3. Die bestehende Regel unverändert in ein Policy Object verschieben.
4. Aufrufer über einen klaren Vertrag anbinden.
5. Varianten nur bei echtem Änderungsdruck als Strategien ergänzen.

Abgrenzung und Entscheidungshilfe

Eine Specification beantwortet typischerweise, ob ein Objekt ein Kriterium erfüllt. Eine Policy kann eine reichere Entscheidung mit Begründung und Folgeschritten liefern.

Enterprise-Java-Einordnung

RefundPolicy entscheidet anhand Betrag, Lieferstatus, Kundensegment und Frist über automatische Erstattung, manuelle Prüfung oder Ablehnung.

Teststrategie

Entscheidungstabellen decken alle Regelkombinationen ab. Versions- und Mandantenvarianten erhalten gemeinsame Contract-Tests.

package com.aydinsude.workbench.catalog;
import java.time.*;
// Refactoring: Extract Policy Object
// Policy Pattern: Veränderliche Fachregeln werden als explizite Entscheidung gekapselt.
public final class RefundPolicy {
  public record Decision(boolean allowed,String reason) {}
  private final Duration window;
  public RefundPolicy(Duration window){ if(window==null||window.isNegative()||window.isZero()) throw new IllegalArgumentException("window"); this.window=window; }
  public Decision evaluate(Instant paidAt,Instant requestedAt,boolean consumed){ if(consumed) return new Decision(false,"already-consumed"); if(requestedAt.isAfter(paidAt.plus(window))) return new Decision(false,"window-expired"); return new Decision(true,"eligible"); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Entwurfsmuster

95. Replace If-Else Chain with Strategy

Sicherer Refactoring-Ablauf

1. Gemeinsamen Eingabe- und Ergebnisvertrag der Varianten bestimmen.
2. Eine Strategy-Schnittstelle einführen.
3. Eine bestehende Verzweigung in eine konkrete Strategy verschieben.
4. Schrittweise weitere Varianten extrahieren.
5. Auswahl über Resolver, Registry oder Composition Root zentralisieren.

Abgrenzung und Entscheidungshilfe

Strategy wird vom Aufrufer oder Resolver ausgewählt. State wechselt typischerweise aufgrund interner Zustandsübergänge des Contexts.

Enterprise-Java-Einordnung

ShippingCostStrategy berechnet Kosten für Standard, Express und Abholung. Ein Resolver wählt anhand des Lieferprodukts, während der Checkout nur den Strategy-Vertrag kennt.

Teststrategie

Contract-Tests prüfen gemeinsame Invarianten aller Strategien. Jede Variante erhält fokussierte Grenzwerttests; Resolvertests prüfen eindeutige Auswahl.

package com.aydinsude.workbench.catalog;
import java.util.*;
// Refactoring: Replace If-Else Chain with Strategy
// Strategy Pattern: Varianten werden ohne wachsende Verzweigung ergänzt.
public final class DeliveryPricing {
  public enum Mode { STANDARD, EXPRESS, PICKUP }
  public interface Strategy { long price(long basketCents); }
  private final Map<Mode,Strategy> strategies;
  public DeliveryPricing(Map<Mode,Strategy> strategies){ this.strategies=Map.copyOf(strategies); }
  public long price(Mode mode,long basketCents){ var strategy=strategies.get(mode); if(strategy==null) throw new IllegalArgumentException("mode"); return strategy.price(basketCents); }
  public static DeliveryPricing defaults(){ return new DeliveryPricing(Map.of(Mode.STANDARD,b->b>=5000?0:490,Mode.EXPRESS,b->990,Mode.PICKUP,b->0)); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Entwurfsmuster

96. Replace Switch with Polymorphic Handler

Sicherer Refactoring-Ablauf

1. Die Fälle und ihren gemeinsamen Dispatch-Vertrag erfassen.
2. Einen typisierten Handlervertrag definieren.
3. Einen Fall vollständig in einen Handler verschieben.
4. Handler über eine explizite Registry registrieren.
5. Switch entfernen, sobald alle Fälle migriert und unbekannte Typen definiert behandelt sind.

Abgrenzung und Entscheidungshilfe

Der polymorphe Handler ist besonders für typisierte Nachrichten oder Befehle geeignet; Strategy beschreibt eher austauschbare Algorithmen für denselben Kontext.

Enterprise-Java-Einordnung

DocumentHandler verarbeitet Invoice, Contract und ClaimDocument. Jeder Handler validiert und transformiert seinen Typ; die Registry lehnt unbekannte Typen explizit ab.

Teststrategie

Contract-Tests prüfen Handlerverträge. Registrytests prüfen doppelte und fehlende Registrierung. Jeder Handler erhält eigene Fachtests.

package com.aydinsude.workbench.catalog;
import java.util.*;
// Refactoring: Replace Switch with Polymorphic Handler
// Polymorphism + Registry: Jeder Handler besitzt genau ein Formatverhalten.
public final class DocumentExportHandlers {
  public interface Handler { String format(); byte[] export(List<String> rows); }
  private final Map<String,Handler> handlers;
  public DocumentExportHandlers(List<Handler> handlers){ var map=new HashMap<String,Handler>(); for(var h:handlers) if(map.put(h.format(),h)!=null) throw new IllegalArgumentException("duplicate"); this.handlers=Map.copyOf(map); }
  public byte[] export(String format,List<String> rows){ var h=handlers.get(format); if(h==null) throw new IllegalArgumentException("format"); return h.export(List.copyOf(rows)); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Entwurfsmuster

97. Introduce Explicit State Machine

Sicherer Refactoring-Ablauf

1. Bestehende Zustände und tatsächlich beobachtete Übergänge dokumentieren.
2. Characterization Tests für gültige und ungültige Abläufe erstellen.
3. Einen zentralen Übergangsvertrag mit Ereignis und Ergebnis einführen.
4. Direkte Statusänderungen schrittweise durch transition(event) ersetzen.
5. Nebenwirkungen von Zustandsänderung trennen und nach erfolgreichem Übergang auslösen.

Abgrenzung und Entscheidungshilfe

State Pattern verteilt Verhalten auf Zustandsobjekte. Eine explizite State Machine kann auch tabellen- oder regelbasiert implementiert sein.

Enterprise-Java-Einordnung

ClaimStateMachine erlaubt SUBMIT, APPROVE, REJECT und PAY abhängig vom aktuellen ClaimStatus. Jede Ablehnung enthält einen fachlichen Grund.

Teststrategie

Eine Übergangsmatrix prüft jede Kombination aus Zustand und Ereignis. Property-Tests sichern, dass geschlossene Zustände keine Änderungen mehr erlauben.

package com.aydinsude.workbench.catalog;
import java.util.*;
// Refactoring: Introduce Explicit State Machine
// State Machine Pattern: Erlaubte Übergänge sind zentral und ausführbar dokumentiert.
public final class TicketStateMachine {
  public enum State { NEW, ASSIGNED, RESOLVED, CLOSED }
  private static final Map<State,Set<State>> ALLOWED=Map.of(State.NEW,Set.of(State.ASSIGNED),State.ASSIGNED,Set.of(State.RESOLVED),State.RESOLVED,Set.of(State.CLOSED),State.CLOSED,Set.of());
  public State transition(State from,State to){ if(!ALLOWED.getOrDefault(from,Set.of()).contains(to)) throw new IllegalStateException(from+" -> "+to); return to; }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Entwurfsmuster

98. Introduce Null Object

Sicherer Refactoring-Ablauf

1. Prüfen, ob für das Fehlen wirklich ein eindeutiges neutrales Verhalten existiert.
2. Einen kleinen Vertrag und eine No-op-Implementierung definieren.
3. Erzeugungs- oder Verdrahtungsstelle so ändern, dass niemals null geliefert wird.
4. Nullprüfungen schrittweise entfernen.
5. Observability prüfen, damit wichtige Fehlkonfigurationen nicht unsichtbar werden.

Abgrenzung und Entscheidungshilfe

Optional macht Abwesenheit sichtbar. Null Object macht sie für Aufrufer transparent. Die Wahl hängt davon ab, ob der fehlende Fall behandelt werden muss.

Enterprise-Java-Einordnung

NoOpAuditPublisher ist nur in lokalen Tests zulässig; produktive Profile verlangen einen echten AuditPublisher. Ein NoDiscountPolicy liefert Money.zero statt null.

Teststrategie

Contract-Tests prüfen, dass das Null Object den Vertrag erfüllt, keine Seiteneffekte auslöst und definierte neutrale Ergebnisse liefert.

package com.aydinsude.workbench.catalog;
// Refactoring: Introduce Null Object
// Null Object Pattern: Fehlende Variante besitzt neutrales Verhalten statt null.
public final class CustomerDiscount {
  public interface Discount { long apply(long cents); }
  public static final Discount NONE=cents->cents;
  private final Discount discount;
  public CustomerDiscount(Discount discount){ this.discount=discount==null?NONE:discount; }
  public long finalPrice(long cents){ if(cents<0) throw new IllegalArgumentException("price"); return discount.apply(cents); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Entwurfsmuster

99. Extract Specification

Sicherer Refactoring-Ablauf

1. Eine wiederkehrende fachliche Bedingung mit klarem Namen auswählen.
2. Einen Specification-Vertrag über den relevanten Typ einführen.
3. Die Bedingung unverändert in eine konkrete Specification verschieben.
4. Komposition für and, or und not kontrolliert ergänzen.
5. Duplikate in Services und Queries schrittweise ersetzen.

Abgrenzung und Entscheidungshilfe

Specification beschreibt ein Kriterium. Strategy führt einen Algorithmus aus. Policy kann eine reichere Entscheidung treffen.

Enterprise-Java-Einordnung

EligibleForAutomaticRefund kombiniert WithinReturnWindow, NotFraudSuspected und AmountBelowLimit. Die Regel kann im Use Case erklärt und separat getestet werden.

Teststrategie

Beispiel- und Grenzwerttests je Specification, Wahrheitstabellen für Kompositionen und Konsistenztests zwischen In-Memory- und Persistenzabfrage.

package com.aydinsude.workbench.catalog;
// Refactoring: Extract Specification
// Specification Pattern: Fachregeln werden benannt, kombiniert und separat getestet.
public interface OrderEligibilitySpecification {
  record Candidate(boolean active,long outstandingCents,String country) {}
  boolean isSatisfiedBy(Candidate candidate);
  default OrderEligibilitySpecification and(OrderEligibilitySpecification other){ return c->isSatisfiedBy(c)&&other.isSatisfiedBy(c); }
  static OrderEligibilitySpecification active(){ return Candidate::active; }
  static OrderEligibilitySpecification debtBelow(long limit){ return c->c.outstandingCents()<limit; }
  static OrderEligibilitySpecification country(String value){ return c->value.equals(c.country()); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Entwurfsmuster

100. Replace Boolean Return with Decision Object

Sicherer Refactoring-Ablauf

1. Alle Informationen erfassen, die Aufrufer nach der Boolean-Entscheidung benötigen.
2. Einen kleinen unveränderlichen Decision-Typ mit Status und fachlichem Grund definieren.
3. Bestehende Methode intern auf Decision umstellen und vorübergehend einen Boolean-Adapter anbieten.
4. Aufrufer schrittweise auf die reichere Entscheidung migrieren.
5. Alte Boolean-Methode entfernen, sobald keine Doppelberechnung mehr existiert.

Abgrenzung und Entscheidungshilfe

Ein Result Type modelliert häufig Erfolg oder technischen/fachlichen Fehler einer Operation. Ein Decision Object beschreibt bewusst das Ergebnis einer Regelbewertung.

Enterprise-Java-Einordnung

CreditDecision enthält APPROVED, MANUAL_REVIEW oder REJECTED, einen ReasonCode, verwendete PolicyVersion und Limit. API, Audit und Workflow nutzen dasselbe Ergebnis.

Teststrategie

Entscheidungstabellen prüfen Status und Reason Code gemeinsam. Serialisierungs- und Kompatibilitätstests sichern öffentliche Decision-Verträge.

package com.aydinsude.workbench.catalog;
// Refactoring: Replace Boolean Return with Decision Object
// Decision Object Pattern: Ergebnis, Begründung und nächster Schritt bleiben zusammen.
public final class CreditDecision {
  public enum Status { APPROVED, REVIEW, REJECTED }
  public record Decision(Status status,String reason,String nextAction) {}
  public Decision decide(int score,long exposureCents){ if(score<500) return new Decision(Status.REJECTED,"score-too-low","notify-customer"); if(exposureCents>500000) return new Decision(Status.REVIEW,"high-exposure","manual-review"); return new Decision(Status.APPROVED,"policy-satisfied","create-contract"); }
}

Deutschsprachige fachliche Grundlagen

Die fachliche Erklärung wurde aus deutschsprachigen Hochschul-, Hersteller- und Überblicksquellen redaktionell zusammengeführt und auf das vorhandene Java-21-Beispiel übertragen. Sie ist keine wortwörtliche Übersetzung oder Kopie einer einzelnen Quelle.

• Hochschule Bielefeld: Refactoring und grundlegende Techniken
• IBM Deutschland: Code-Refactoring
• Deutschsprachige Übersicht: Entwurfsmuster