Hvordan du unngår anti-mønstre i iOS-programmer - dummies

Hvis du bruker standard prosess og regler for Objektorientert (OO) -design for iOS-appskaping, bør designene dine være robuste. Men selv med en lydprosess og riktige retningslinjer kan du opprette et antimønster. Antimønstre oppstår når en klasse arver funksjonalitet gjennom en upassende tilkobling.

Selv om du er en erfaren utvikler, kan du få ting dårlig feil som resulterer i en ikke-funksjonell design. Følgende dekker bestemte måter du kan få feil på.

Anti-mønstre dekker en rekke fallgruver fra organisasjonsdesign og prosjektledelse til programmering. Her er et par antimønstre som er relevante for OO-design:

• Det såkalte Base Bean-antimønsteret: Her er en klasse arvet fra en annen klasse fordi superklassen inneholder funksjonalitet som trengs i underklassen.

  Anta at du implementerer en ordboks klasse der du kan slå opp ordets betydninger. Et hashbord, hvor ordene er hashed for å finne sine betydninger, er en rimelig datastruktur som skal brukes i en ordbok.

  Men det er ikke bra å lage ordlisten din fra et hashbord. Ordboken din slutter å ha metoder i grensesnittet som ikke har noen forbindelse med ord og deres betydninger. Omvendt har klassen din metoder som har alt å gjøre med ordbøker, men ingenting i det hele tatt med hashbord.

  Basebønner oppstår vanligvis når en programvareutvikler forvirrer et IS-A forhold, som er egnet for å representere en sann underklasse via arv, med et HAS-A forhold, som bedre betjenes av et inneslutningsforhold. Med andre ord, en ordbok kan ha en Hash-tabell, men er ikke et Hash-tabell.

  Merk at OO-designprosessen som er beskrevet, krever at du prøver å bli enige om en kort, skarp definisjon for hver potensiell klasse før du løfter den for å bli en kandidatklasse. Dette hjelper deg med å unngå Base Bean-antimønsteret.

• Den anemiske domenemodellen: Noen grupper, spesielt Enterprise Java-fellesskapet, tenker på domenemodellklasser som bare består av getters og setters for attributter i klassen, uten domeneradferd i klassen (for eksempel, valideringer, beregninger, forretningsregler og lignende). Denne typen design er i strid med OO tenkning.