Transformeer optionele eienskappe in leë versameling vir skoonder, veiliger en polymorfiese kode, wat die miljard-dollar-fout verdryf
TL;DR: vervang herroepbare optionele attribute met leë versameling om nulskoeke te elimineer en polimorfisme te hef.
TL;DR: vervang herroepbare optionele attribute met leë versameling om nulskoeke te elimineer en polimorfisme te hef.
Die probleme wat opgelos word
- Nul verwysings uitsonderings
- Oormaatlike voorwaardelike logika en IF's
- Fragiele foutbehandeling
- Optionele eienskappe
- Kompleks Validasie Kode
- Polimorfisme oortreding
Geskiedenis van die geur
Die stappe
- Identifiseer herroepbare optionele attribute wat versameling kan wees
- Vervang enkele vervalbare voorwerpe met leë versameling
- Verwyder alle null-kontrole wat verband hou met hierdie optionele attribute
- Opdater metodes om met versameling te werk in plaas van enkele voorwerpe
Sample kode
Voordat die
public class ShoppingCart {
private List<Item> items = new ArrayList<>();
private Coupon coupon = null;
public void addItem(Item item) {
this.items.add(item);
}
public void redeemCoupon(Coupon coupon) {
this.coupon = coupon;
}
public double total() {
double total = 0;
for (Item item : this.items) {
total += item.getPrice();
}
// This a polluted IF and null check
if (this.coupon != null) {
total -= this.coupon.getDiscount();
}
return total;
}
public boolean hasUnsavedChanges() {
// Explicit null check
return !this.items.isEmpty() || this.coupon != null;
}
public boolean hasCoupon() {
return this.coupon != null;
}
}
public class ShoppingCart {
private final List<Item> items = new ArrayList<>();
// This version uses Optionals
// Not all programming languages support this feature
private Optional<Coupon> coupon = Optional.empty();
public void addItem(Item item) {
items.add(item);
}
public void redeemCoupon(Coupon coupon) {
// You need to understand how optionals work
this.coupon = Optional.ofNullable(coupon);
}
public boolean hasUnsavedChanges() {
return !items.isEmpty() || !coupon.isPresent();
}
public boolean hasCoupon() {
return coupon.isPresent();
}
}
Na die
public class ShoppingCart {
private List<Item> items = new ArrayList<>();
// 1. Identify nullable optional attributes
// that could be collections
// 2. Replace single nullable objects with empty collections
private List<Coupon> coupons = new ArrayList<>();
public void addItem(Item item) {
this.items.add(item);
}
// Step 4: Work with collection
// instead of single nullable object
public void redeemCoupon(Coupon coupon) {
this.coupons.add(coupon);
}
// Step 4: Simplified logic without null checks
public double total() {
double total = 0;
for (Item item : this.items) {
total += item.getPrice();
}
// 3. Remove all null checks
// related to these optional attributes
for (Coupon coupon : this.coupons) {
total -= coupon.getDiscount();
}
return total;
}
// Consistent behavior with empty collections
public boolean hasUnsavedChanges() {
// 4. Update methods to work with collections
// instead of single objects
return !this.items.isEmpty() || !this.coupons.isEmpty();
}
// 3. Remove all null checks
// related to these optional attributes
// Collection-based check instead of null check
public boolean hasCoupon() {
return !this.coupons.isEmpty();
}
}
Die tipe
- [x] Semi-Automaat
Veiligheid ️
Hierdie refaktoring is oor die algemeen veilig wanneer u al die toegangspunte van die versamelingattribute beheer.
Jy moet verseker dat geen eksterne kode null-waardes verwag nie en die interne API's hanteer.
Die refaktoring handhaaf dieselfde eksterne gedrag terwyl interne logika vereenvoudig word.
Jy moet seker maak dat alle konstruktors en fabrieksmetodes versamelings behoorlik inisialiseer.
Hoekom is die kode beter?
Die hervormde kode verwyderNul pointer uitsonderingsen verminder die voorwaardelike kompleksiteit.
Leë versamelings en nie-leë versamelings gedra polymorfies, wat jou toelaat om hulle uniforme te behandel.
Die kode word meer voorspelbaar aangesien versameling altyd bestaan (ten minste leeg) en reageer op dieselfde operasies.
Metode-implementasies word korter en meer gefokus op besigheidslogika eerder as nulbestuur.
Die benadering is in ooreenstemming met die beginsel om onwettige state onverteerbaar te maak in jou domeinmodel, wat lei tot meer robuuste en onderhoubare kode.
Leë versameling en nie-leë versameling ispolymorphic.
Hoe maak dit die bijection beter? ️
In die werklike wêreld bestaan containers selfs wanneer hulle leeg is.
Deur optionele versamelings as leë versamelings in plaas van nul te verteenwoordig, skep u 'n meer akkurate model van werklikheid.
Null bestaan nie in die werklike wêreld nie, en dit breek altyd dieBijeksie.
Dit handhaaf die een-tot-een ooreenkoms tussen werklike wêreld konsepte en jou berekeningsmodel, wat 'n goeieKaart.
Wanneer u 'n versameling in plaas van nulls retourneer, verminder u ook dieKoppeling.
Beperkings ☀️
Hierdie refaktoring is dalk nie geskik wanneer null 'n semantiese betekenis anders as "leeg" het nie.
U moet verseker dat alle kode pads samelewings konsekwent inisialiseer om gemengde null- en leë state te vermy.
Refleksie met die
Voorgestelde spoor: 1. Identifiseer herroepbare facultatiewe eienskappe wat versamels kan wees 2. Vervang enkele herroepbare voorwerpe met leë versamels 3. Verwyder al die null kontrole wat verband hou met hierdie optionele eienskappe 4. Opdater metodes om met versamels te werk in plaas van enkele voorwerpe 5. Toets dat leë en nie-leë versamels konsekwent gedra
Voorgestelde spoor: 1. Identifiseer herroepbare facultatiewe eienskappe wat versamels kan wees 2. Vervang enkele herroepbare voorwerpe met leë versamels 3. Verwyder al die null kontrole wat verband hou met hierdie optionele eienskappe 4. Opdater metodes om met versamels te werk in plaas van enkele voorwerpe 5. Toets dat leë en nie-leë versamels konsekwent gedra
|
Without Proper Instructions |
With Specific Instructions |
|---|---|
Volgende jaar ️
- Nul
Die vlak
- [x] Die middelste
Gerelateerde verwysings
Dit is die
Krediet
Foto deurEk het k.dieDie Pixabay
Hierdie artikel is deel van die Refactoring-reeks.
