„Sie sollten defensiv programmieren und davon ausgehen, dass Kunden Ihrer Klasse ihr Bestes tun, um ihre Invarianten zu zerstören“
Java als sichere Sprache:
- Java verhindert Speicherfehler, die in C/C++ häufig vorkommen, isoliert Klassen jedoch nicht vollständig von unerwünschten Interaktionen mit anderen Klassen.
- Defensive Programmierung ist erforderlich, vorausgesetzt, dass Clients der Klasse versuchen könnten, ihre Invarianten zu verletzen.
Unveränderliche Klassen und Sicherheit:
- Beispiel für die Klasse „Period“, die unveränderlich erscheint, aber aufgrund der Veränderlichkeit von Objekten wie Datum beschädigt werden kann.
- Lösung: Erstellen Sie defensive Kopien veränderlicher Parameter, wenn Sie diese im Konstruktor empfangen.
public Period(Date start, Date end) {
this.start = new Date(start.getTime()); // Cópia defensiva
this.end = new Date(end.getTime());
if (this.start.compareTo(this.end) > 0)
throw new IllegalArgumentException(start + " after " + end);
}
Nach dem Login kopieren
Verteidigungskopien in Buildern:
- Vor der Validierung von Parametern müssen defensive Kopien erstellt werden, um Schwachstellen (z. B. TOCTOU-Angriff) zu vermeiden.
- Vermeiden Sie die Verwendung von clone() für defensive Kopien potenziell nicht vertrauenswürdiger Objekte und bevorzugen Sie statische Konstruktoren oder Factory-Methoden.
Getter und Veränderlichkeit:
- Problem: Getter können veränderliche interne Komponenten freilegen, was externe Mutationen ermöglicht.
- Lösung: Getter sollten defensive Kopien veränderlicher Objekte zurückgeben.
public Date getStart() {
return new Date(start.getTime()); // Cópia defensiva
}
Nach dem Login kopieren
Anwendung auf veränderliche Klassen:
- Defensives Kopieren gilt auch für veränderbare Klassen, die Verweise auf vom Client bereitgestellte veränderbare Objekte speichern.
- Beispiel: Beim Speichern eines Objekts in einem Set oder einer Map muss berücksichtigt werden, ob das Objekt später geändert werden kann.
Rückgabe interner Komponenten:
- Wenn Sie veränderliche Interna zurückgeben, denken Sie darüber nach, defensive Kopien oder unveränderliche Ansichten zurückzugeben.
Verwendung unveränderlicher Objekte:
- Verwenden Sie nach Möglichkeit unveränderliche Objekte als interne Komponenten, um die Notwendigkeit defensiver Kopien zu vermeiden.
Kosten und Alternativen:
- Defensive Kopien können die Leistung beeinträchtigen; Alternativen sind der Rückgriff auf Dokumentation oder klare Nutzungsvereinbarungen.
- Bei expliziter Kontrollübertragung, etwa bei Designmustern (z. B. Wrapper), kann auf eine defensive Kopie verzichtet werden.
Fazit:
- Verwenden Sie defensive Kopien, um die Integrität des Unterrichts zu schützen, es sei denn, die Kosten sind unpraktisch oder es besteht gegenseitiges Vertrauen und eine klare Dokumentation ist erforderlich.
Beispiele aus dem Buch:
Das obige ist der detaillierte Inhalt vonGegenstand Erstellen Sie bei Bedarf Verteidigungskopien. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!