Bedste svar
Ja, du skriver de samme slags og søgninger og strenghåndteringsfunktioner tusinder af gange, hver kun en mindreårig sidste gangs variation.
Dette er så sandt, at der i den akademiske verden er opstået en sundhedsbesparende filosofi, der hedder “Dont Repeat Yourself”, som foregiver, at der er en måde at ikke skrive den samme kode over og over.
Dette dumme mantra skal virkelig slås ud af mennesker.
Smart design betyder ikke at skulle starte fra bunden hver gang, og smart kodning betyder at vide, hvornår man skal skrive noget ny, og hvornår kode skal genbruges.
Genanvendelse af kode som en tidsbesparende, fejlsøgningsforanstaltning har sine fordele, når den er tilgængelig. Dette har udviklet sig til nyttige værktøjer såsom generiske og skabeloner og begrebet arv og universelle APIer, så sortering og søgning bliver generisk i stedet for at der skal skrives en ny søgefunktion til hver type array eller liste.
Kopiering af kodetekst betragtes som den værste fejl, fordi den kopierer bugs og bloat-kode, og er primært det, der betragtes som overflødig.
Det er her, arv skinner som en kode-reduktionsstrategi. Underklasser behøver ikke at være dyre omskrivninger af deres basisklasser, hvis det meste af den funktionalitet, der er fælles for alle underklasser, placeres i basisklassen. Mange gange kan underklassen kalde baseklassefunktionen og derefter udføre et par ændringer selv i stedet for at genimplementere hele funktionen. Det er det, de taler om.
Men “Dont Repeat Yourself” har fået kultstatus i fora som denne som en slags ideel måde at kode og design på, og det er bare ikke sandt eller praktisk eller en del af et hvilket som helst større kodesæt i den virkelige verden.
Overdesign er til sprogudviklere, teoretikere og Framework-skabere. Praktiske kodere skriver bare kode, der fungerer, og hvis dit program har to klasser, der begge implementerer binær søgning, ja hvad så. Har du virkelig brug for en tredje klasse med underklasser til at håndtere binære søgninger efter de to andre dataklasser? Måske, men det handler om at skalere en størrelse af dataklasser med behov for binær søgning, så bliver det en realtid og fejlbesparende at have en klasse, der gør det korrekt, og som kan underklassificeres til at håndtere dataklassens behov. Ser du?
Programmering i det store kræver meget mere planlægning og analyse af arbejdsdeling end programmering af små job og værktøjer. Så ja, hvis du har et projekt med over 1000 linjer kode, skal du kigge over designet og finde overflødige algoritmer og funktioner og beslutte, om du kan samle dem i en enkelt funktionel hjælpeklasse eller to og dele kode til alle dataobjekterne. Men gør det ikke til en religiøs søgen efter ultimativ redundans-eliminering. Og tro ikke dem, der gør det.
Svar
Hvis det er den mest effektive løsning, er det ikke dårlig praksis. At gøre noget , der har en enklere og mere elegant løsning, der dog er let tilgængelig, men er en dårlig praksis .
I dette tilfælde kan en gigantisk switch ofte erstattes af en grænseflade eller lade en klasse have sit eget ansvar osv.
For eksempel, hvis du har noget som dette :
Denne fungerer . Koden vil være slags robust, så længe værdier kun tilføjes og ikke redigeres, og den er faktisk endda ret effektiv, da bit sammenligninger tager næsten nul tid. Men dette vil komme ud af kontrol, svært at navigere, og du allerede er nødt til at definere disse bilklasser alligevel.
I stedet lad os starte med noget som dette:
Igen havde vi sandsynligvis dette alligevel, bare uden metoden numberOfCylinders, og så nu vores første metode ser bare sådan ud:
Forestil dig nu et øjeblik, at vi er en national auto-butik, og vi har bogstaveligt talt tusinder af biler af forskellige mærker, modeller, trimmer osv. At hvis / ellers ville blive et enormt monster, umuligt at læse, ekstremt svært at sikkert tilføje til eller fjerne fra osv.
Så igen , det er ikke altid en dårlig praksis, og nogle gange har vi brug for en stor switch eller noget lignende, men normalt er der en lettere måde at gemme sig derinde.
REDIGER: Der er mange kommentarer om at have en n ekstremt stort antal bilkombinationer (potentielt millioner på tværs af historien) og klasser, der implementerer bil, der fejler her. Selvfølgelig vil klasser på et bestemt tidspunkt ikke fungere, og du vil gemme flade filer i en database og bruge en accessor.
Mit svar var beregnet til at vise faldgruben ved at bruge meget lang betingede udsagn, ikke som et faktisk forsøg på at opbygge en butikarkitektur til bildele.Hvis du arbejder hos en større bilforhandler, skal du ikke tage mit enkle svar som basis for din softwarearkitektur 🙂