Bästa svaret
Ja, du kommer att skriva samma sorter och sökningar och stränghanteringsfunktioner tusentals gånger, var och en bara en mindre förra gångens variation.
Detta är så sant att en sanitetssparande filosofi som förnekar den har uppstått i den akademiska världen som heter ”Dont Repeat Yourself” som låtsas att det finns ett sätt att inte skriva samma kod över och över.
Detta dumma mantra måste verkligen slås av människor.
Smart design innebär att du inte behöver börja om från början varje gång, och smart kodning innebär att veta när man ska skriva något ny och när kod ska återanvändas.
Kodåteranvändning som en tidsbesparande, felsökningsåtgärd har sina fördelar när den är tillgänglig. Detta har utvecklats till användbara verktyg som generik och mallar och begreppet arv och universella API: er så att sortering och sökning blir generisk istället för att en ny sökfunktion måste skrivas för varje typ av matris eller lista.
Kopiering av kodtext anses vara det värsta felet eftersom det kopierar buggar och uppblåst kod och är främst vad som anses vara överflödigt.
Det är här arv lyser som en kodreduceringsstrategi. Underklasser behöver inte vara dyra omskrivningar av sina basklasser om de flesta funktioner som är gemensamma för alla underklasser läggs i basklassen. Många gånger kan underklassen ringa basklassfunktionen och sedan utföra några ändringar i stället för att återinföra hela funktionen. Det är vad de pratar om.
Men ”Dont Repeat Yourself” har fått kultstatus i forum som detta som ett slags idealiskt sätt att koda och designa, och det är helt enkelt inte sant eller praktisk eller del av någon större kodkod i verklig värld.
Överdesign är för språkutvecklare, teoretiker och Framework-skapare. Praktiska kodare skriver bara kod som fungerar, och om ditt program har två klasser som båda implementerar binär sökning, ja vad så. Behöver du verkligen en tredje klass med underklasser för att hantera binära sökningar för de andra två dataklasserna? Kanske, men det handlar om att skala upp en omfattning av dataklasser med behov av binär sökning, då blir det en realtid och felbesparare att ha en klass som gör det korrekt som kan delklassas för att hantera dataklassens behov. Ser du?
Programmering i stort kräver mycket mer planering och analys av arbetsfördelning än programmering av små jobb och verktyg. Så ja, om du har ett projekt med över 1000 rader kod, titta över designen och hitta redundanta algoritmer och funktioner, och bestäm om du kan samla dem i en enda funktionell verktygsklass eller två och dela kod för alla dataobjekten. Men gör det inte till en religiös strävan efter ultimat redundans-eliminering. Och tro inte dem som gör det.
Svar
Om det är det mest effektiva alternativet är det inte dålig praxis. Att göra vad som helst som har en enklare och mer elegant lösning som är lättillgängligt men är en dålig praxis .
I det här fallet kan en gigantisk switch ofta ersättas av ett gränssnitt eller låta en klass ha sitt eget ansvar etc.
Till exempel om du har något liknande :
Detta fungerar . Koden kommer att vara typ av robust så länge värden bara läggs till och inte redigeras, och den är faktiskt till och med ganska effektiv eftersom bitjämförelser tar praktiskt taget noll tid. Men detta kommer att bli utom kontroll, svårt att navigera och du redan måste definiera dessa bilklasser ändå.
Istället, låt oss börja med något så här:
Återigen hade vi förmodligen det här ändå, utan metoden numberOfCylinders, och så nu vår första metoden ser bara ut så här:
Tänk dig för ett ögonblick att vi är en nationell bildelbutik, och vi har bokstavligen tusentals bilar av olika märken, modeller, trim osv. Att om / annat skulle bli ett enormt monster, omöjligt att läsa, extremt svårt att säkert lägga till eller ta bort från osv.
Så igen , det är inte alltid en dålig praxis, och ibland behöver vi en stor switch eller något liknande, men vanligtvis finns det ett enklare sätt att gömma sig där inne.
EDIT: Det finns många kommentarer om att ha en ett extremt stort antal bilkombinationer (potentiellt miljoner över historien) och klasser som implementerar bil som misslyckas här. Naturligtvis vid en viss punkt kommer klasser inte att fungera, och du skulle lagra platta filer i en databas och använda en accessor.
Mitt svar var tänkt att visa fallgropen att använda mycket lång villkorliga uttalanden, inte som ett faktiskt försök att bygga en arkitektur för bildelar.Om du arbetar hos en större bilhandlare, vänligen ta inte mitt enkla svar som grund för din programvaruarkitektur 🙂