Je psaní nadbytečného kódu špatnou praxí?


Nejlepší odpověď

Ano, budete psát stejné druhy a vyhledávací funkce a funkce pro manipulaci s řetězci tisíckrát, každý jen menší varianta poslední doby.

To je tak pravda, že v akademické sféře vznikla filozofie šetřící zdravý rozum, která ji popírá a která se předstírá, že existuje způsob, jak nenapsat stejný kód a znovu.

Tuto hloupou mantru je opravdu třeba porazit.

Inteligentní design znamená, že nemusíte vždy začínat od nuly a inteligentní kódování znamená vědět, kdy něco napsat nové a kdy znovu použít kód.

Opětovné použití kódu jako opatření šetřící čas a ladění má své opodstatnění, pokud je k dispozici. Toto se vyvinulo v užitečné nástroje, jako jsou obecné a šablony a koncept dědičnosti a univerzální API, takže třídění a vyhledávání se stávají obecnými, místo aby bylo nutné pro každý typ pole nebo seznamu psát novou vyhledávací funkci.

Kopírování textu kódu je považováno za nejhorší chybu, protože kopíruje chyby a nafouklé kódy, a je primárně považováno za nadbytečné.

Toto je místo, kde dědičnost září jako strategie redukce kódu. Podtřídy nemusí být nákladné přepisování jejich základních tříd, pokud je většina funkcí společných pro všechny podtřídy vložena do základní třídy. Mnohokrát podtřída může volat funkci základní třídy a poté provést několik změn sama, než aby znovu implementovala celou funkci. To je to, o čem mluví.

Ale „Neopakujte se“ získalo na takových fórech kultovní status jako nějaký ideální způsob kódování a designu a prostě to není pravda nebo praktické nebo součástí jakéhokoli významného souboru kódu v reálném světě.

Nadměrný design je určen pro vývojáře jazyků, teoretiky a tvůrce rámců. Praktické programátory prostě píší kód, který funguje, a pokud má váš program dvě třídy, které obě implementují binární vyhledávání, no a co. Opravdu potřebujete třetí třídu s podtřídami, abyste zvládli binární vyhledávání dalších dvou datových tříd? Možná, ale to je o zvětšení velikosti datových tříd s potřebou binárního vyhledávání, pak se stane v reálném čase a spořičem chyb mít třídu, která to dělá správně, která může být podtřída, aby zvládla potřeby datových tříd. Vidíte?

Programování ve velkém vyžaduje mnohem více plánování a analýzy dělby práce než programování malých úloh a nástrojů. Takže ano, pokud máte projekt s více než 1000 řádky kódu, podívejte se na design a najděte redundantní algoritmy a funkce a rozhodněte se, zda je můžete shromáždit do jedné funkční třídy nebo dvou a sdílet kód pro všechny datové objekty. Ale nedělejte to v náboženském hledání konečné eliminace nadbytečnosti. A nevěřte těm, kteří tomu věří.

Odpověď

Pokud je to nejefektivnější možnost, pak to není špatný postup. Dělat cokoli , které má snadno dostupné a elegantnější řešení, je však špatný postup .

V tomto případě může být obří přepínač často nahrazen rozhraním nebo třídou, která má vlastní odpovědnost atd.

Například pokud máte něco takového :

Toto bude fungovat. Kód bude jaksi robustní, pokud budou hodnoty pouze přidávány a nebudou upravovány, a ve skutečnosti je dokonce docela efektivní, protože bitová srovnání trvají prakticky nulový čas. Ale to se vymkne kontrole, bude obtížné se v ní zorientovat a vy již musíte tyto třídy automobilů stejně definovat.

Místo toho začněme s něčím podobným:

Znovu jsme to pravděpodobně měli, jen bez metody numberOfCylinders, a tak nyní náš první metoda vypadá jen takto:

Nyní si na chvíli představte, že jsme národním obchodem s autodíly a máme doslova tisíce aut různých značek, modelů, ozdob atd. Že kdyby se / else stalo obrovským monstrem, nemožné číst, extrémně těžko bezpečně přidat nebo odebrat atd.

Takže znovu , není to vždy špatný postup a někdy budeme potřebovat velký přepínač nebo něco podobného, ​​ale obvykle se tam skrývá jednodušší způsob.

EDIT: Existuje mnoho komentářů o tom, že n extrémně velký počet kombinací automobilů (potenciálně miliony v celé historii) a tříd implementujících zde selhávající auto. Samozřejmě v určitém okamžiku třídy nebudou fungovat a budete ukládat ploché soubory do databáze a používat přístupový objekt.

Moje odpověď měla ukázat úskalí používání velmi dlouhých podmíněné příkazy, nikoli jako skutečný pokus o vytvoření architektury obchodu s náhradními díly.Pokud pracujete u významného prodejce automobilů, neberte moji jednoduchou odpověď jako základ architektury vašeho softwaru 🙂

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *