Beste svaret
Ja, du kommer til å skrive de samme typene og søk og strenghåndteringsfunksjoner tusenvis av ganger, hver bare en mindreårig siste gang.
Dette er så sant at en sunnhetssparende filosofi som nekter den, har oppstått i akademia kalt «Dont Repeat Yourself» som later som det er en måte å ikke skrive den samme koden over og over.
Dette dumme mantraet trenger virkelig å bli slått ut av mennesker.
Smart design betyr at du ikke trenger å starte fra bunnen av hver gang, og smart koding betyr å vite når du skal skrive noe ny og når du skal bruke kode på nytt.
Gjenbruk av koder som et tidsbesparende, feilsøkingsmål har sine fordeler når den er tilgjengelig. Dette har utviklet seg til nyttige verktøy som generikk og maler og konseptet med arv og universelle API-er, slik at sortering og søk blir generisk i stedet for at det trenger å skrives en ny søkefunksjon for alle typer matriser eller lister.
Kopiering av kodetekst betraktes som den verste feilen fordi den kopierer feil og oppblåst kode, og er først og fremst det som betraktes som overflødig.
Det er her arv skinner som en kodeneduksjonsstrategi. Underklasser trenger ikke å være dyre omskrivninger av basisklassene hvis det meste av funksjonaliteten som er felles for alle underklasser, blir lagt inn i basisklassen. Mange ganger kan underklassen ringe til baseklassefunksjonen og deretter utføre noen få endringer selv, i stedet for å implementere hele funksjonen på nytt. Det er det de snakker om.
Men «Dont Repeat Yourself» har fått kultstatus i forum som dette som en slags ideell måte å kode og designe, og det er bare ikke sant eller praktisk eller en del av en hvilken som helst større kodekropp.
Overdesign er for språkutviklere, teoretikere og Framework-skapere. Praktiske kodere skriver bare kode som fungerer, og hvis programmet ditt har to klasser som begge implementerer binært søk, vel så hva. Trenger du virkelig en tredje klasse med underklasser for å håndtere binære søk etter de to andre dataklassene? Kanskje, men det handler om å skalere opp en mengde dataklasser med behov for binært søk, så blir det en sanntid og feilsparer å ha en klasse som gjør det riktig som kan underklasseres for å håndtere dataklassens behov. Ser du?
Programmering i det store krever mye mer planlegging og analyse av arbeidsdeling enn programmering av små jobber og verktøy. Så ja, hvis du har et prosjekt med over 1000 linjer med kode, kan du se over designet og finne overflødige algoritmer og funksjoner, og bestemme om du kan samle dem i en enkelt funksjonell nytteklasse eller to og dele kode for alle dataobjektene. Men ikke gjør det til en religiøs søken etter ultimate redundans-eliminering. Og ikke tro de som gjør det.
Svar
Hvis det er det mest effektive alternativet, er det ikke dårlig praksis. Å gjøre hva som helst som har en enklere og mer elegant løsning som er lett tilgjengelig skjønt, er en dårlig praksis .
I dette tilfellet kan en gigantisk bryter ofte erstattes av et grensesnitt eller la en klasse ha sitt eget ansvar osv.
Hvis du for eksempel har noe som dette :
Denne fungerer . Koden vil være ganske robust så lenge verdiene bare blir lagt til og ikke redigert, og den er til og med ganske effektiv, siden bitesammenligninger tar praktisk talt null tid. Men dette vil komme ut av kontroll, vanskelig å navigere, og du allerede må definere disse bilklassene uansett.
I stedet, la oss starte med noe sånt som dette:
Igjen hadde vi sannsynligvis dette uansett, bare uten numberOfCylinders-metoden, og så nå vår første metoden ser bare slik ut:
Tenk deg nå et øyeblikk at vi er en nasjonal bildelerbutikk, og vi har bokstavelig talt tusenvis av biler av forskjellige merker, modeller, pynt osv. At hvis / annet ville bli et enormt monster, umulig å lese, ekstremt vanskelig å trygt legge til eller fjerne fra osv.
Så igjen , det er ikke alltid en dårlig praksis, og noen ganger trenger vi en stor bryter eller noe sånt, men vanligvis er det en enklere måte å gjemme seg der inne.
REDIGER: Det er mange kommentarer om å ha en et ekstremt stort antall bilkombinasjoner (potensielt millioner på tvers av historien) og klasser som implementerer Car failing her. Selvfølgelig, på et bestemt tidspunkt, vil ikke klasser fungere, og du vil lagre flate filer i en database og bruke en accessor.
Svaret mitt var ment å vise fallgruven ved å bruke veldig lang tid betingede uttalelser, ikke som et faktisk forsøk på å bygge en arkitektur for bildeler.Hvis du jobber hos en stor bilforhandler, må du ikke ta mitt enkle svar som grunnlag for programvarearkitekturen din 🙂