Beste antwoord
Ja, je gaat duizenden keren dezelfde soorten en zoekopdrachten schrijven en dezelfde tekenreeksafhandelingsfuncties, elk slechts een kleine variatie van de laatste keer.
Dit is zo waar dat er in de academische wereld een filosofie voor het redden van gezond verstand is ontstaan, genaamd “Dont Repeat Yourself”, die beweert dat er een manier is om niet dezelfde code te overschrijven en meer.
Deze stomme mantra moet echt uit mensen worden geslagen.
Slim ontwerp betekent dat je niet elke keer helemaal opnieuw hoeft te beginnen, en slimme codering betekent dat je weet wanneer je iets moet schrijven nieuw en wanneer code opnieuw moet worden gebruikt.
Hergebruik van code als een tijdbesparende, foutopsporingsmaatregel heeft zijn voordelen, wanneer deze beschikbaar is. Dit is geëvolueerd naar handige tools zoals generieke en sjablonen en het concept van overerving en universele APIs, zodat sorteren en zoeken generiek wordt in plaats van dat er een nieuwe zoekfunctie moet worden geschreven voor elk type array of lijst.
Het kopiëren van codetekst wordt als de ergste fout beschouwd, omdat het bugs en bloats-code kopieert, en in de eerste plaats wat als overbodig wordt beschouwd.
Dit is waar overerving schittert als een strategie voor het verminderen van code. Subklassen hoeven geen dure herschrijvingen van hun basisklassen te zijn als de meeste functionaliteit die alle subklassen gemeen hebben, in de basisklasse wordt gestopt. Vaak kan de subklasse de basisklasse-functie aanroepen en vervolgens zelf een paar wijzigingen aanbrengen, in plaats van de hele functie opnieuw te implementeren. Dat is waar ze het over hebben.
Maar de “Dont Repeat Yourself” heeft op dit soort forums een cultstatus gekregen als een soort ideale manier om te coderen en ontwerpen, en het is gewoon niet waar of praktisch of onderdeel van een grote hoeveelheid code uit de echte wereld.
Over-design is voor taalontwikkelaars, theoretici en Framework-makers. Praktische codeerders schrijven gewoon code die werkt, en als je programma twee klassen heeft die beide binair zoeken implementeren, nou wat dan. Heeft u echt een derde klasse met subklassen nodig om binaire zoekopdrachten voor de andere twee gegevensklassen af te handelen? Misschien, maar dat gaat over het opschalen van een groot aantal dataklassen met behoefte aan binair zoeken, dan wordt het een real-time en bug-saver om een klasse te hebben die dat correct doet en die kan worden onderverdeeld om de behoeften van de dataklassen af te handelen. Zie je?
Programmeren in het groot vergt veel meer planning en analyse van de taakverdeling dan het programmeren van kleine taken en tools. Dus ja, als je een project hebt met meer dan 1000 regels code, bekijk dan het ontwerp en vind overtollige algoritmen en functies, en beslis of je ze in een enkele functionele utility class of twee kunt verzamelen en code kunt delen voor alle data-objecten. Maar maak er geen religieuze zoektocht van naar de ultieme uitbanning van overtolligheid. En geloof degenen die dat wel doen niet.
Antwoord
Als dit de meest efficiënte optie is, dan is het geen slechte gewoonte. alles doen waarvoor een eenvoudigere, elegantere oplossing direct beschikbaar is, is een slechte gewoonte .
In dit geval kan een gigantische schakelaar vaak worden vervangen door een interface of een klas zijn eigen verantwoordelijkheid laten hebben, enz.
Bijvoorbeeld, als je zoiets hebt :
Deze zal werken. De code zal een beetje robuust zijn zolang waarden alleen worden toegevoegd en niet bewerkt, en het is zelfs behoorlijk efficiënt omdat bitvergelijkingen vrijwel geen tijd kosten. Maar dit zal uit de hand lopen, moeilijk te navigeren zijn, en u al moet deze autoklassen toch al definiëren.
Laten we in plaats daarvan beginnen met zoiets als dit:
Nogmaals, we hadden dit waarschijnlijk toch, alleen zonder de numberOfCylinders-methode, en dus nu onze eerste methode ziet er gewoon als volgt uit:
Stel je nu eens voor dat we een nationale auto-onderdelenwinkel zijn, en we hebben letterlijk duizenden autos van verschillende merken, modellen, uitrustingsstukken, enz. Dat als / anders een enorm monster zou worden, onmogelijk te lezen, extreem moeilijk om veilig toe te voegen of te verwijderen, enz.
Dus nogmaals , het is niet altijd een slechte gewoonte, en soms hebben we een grote omschakeling of iets dergelijks nodig, maar meestal is er een gemakkelijkere manier om je daarin te verstoppen.
BEWERK: Er zijn veel opmerkingen over het hebben van een n extreem groot aantal auto-combinaties (mogelijk miljoenen in de geschiedenis) en klassen die hier auto falen. Natuurlijk gaan klassen op een gegeven moment niet werken, en zou je platte bestanden in een database opslaan en een accessor gebruiken.
Mijn antwoord was bedoeld om de valkuil te laten zien van het gebruik van zeer lange voorwaardelijke verklaringen, niet als een daadwerkelijke poging om een auto-onderdelenwinkelarchitectuur te bouwen.Als u bij een grote autohandelaar werkt, neem dan mijn simpele antwoord niet als basis voor uw softwarearchitectuur 🙂