3 krachtige codeertechnieken om rommelige conditionals te verwijderen

Bij softwareontwikkeling komen we vaak code logica tegen die meerdere scenario's moet afhandelen. Als deze niet goed beheerd worden, kunnen deze logica's gemakkelijk uitgroeien tot lange if-else ketens of massieve switch-instructies. Dit artikel zal verschillende effectieve technieken introduceren om deze structuren te optimaliseren, waardoor de codekwaliteit en onderhoudbaarheid worden verbeterd.

1. Defensief programmeren: vroege terugkeer#

Stel dat we een gebruikersauthenticatiesysteem ontwikkelen dat verschillende gebruikersstatussen moet controleren voordat toegang wordt verleend:

Deze code heeft duidelijke structurele problemen. Het gebruikt diep geneste if-else structuren, waardoor de code moeilijk te lezen en te onderhouden is. Naarmate het aantal conditiecontroles toeneemt, wordt de inspringingsniveau van de code dieper, wat leidt tot zogenaamde "pijlvormige" code. Foutafhandelingslogica is verspreid over verschillende genestnivale, wat niet bevorderlijk is voor eenheidbeheer. Belangrijker nog, de kernlogica van de code—het geval waarin toegang is toegestaan—is diep verborgen in meerdere lagen van conditionele beoordelingen, wat het intuïtiever minder maakt. Deze codestijl vermindert niet alleen de leesbaarheid van de code, maar verhoogt ook het risico op fouten en maakt code-uitbreiding moeilijk.

We kunnen deze code optimaliseren met de "vroege terugkeer" benadering:

Door de "vroege terugkeer" strategie toe te passen, hebben we met succes de oorspronkelijke code structuur geoptimaliseerd.

Deze methode brengt verschillende verbeteringen:

• Het vermindert significant de nestingscomplexiteit van de code. Elke voorwaarde wordt onafhankelijk afgehandeld, waardoor de algehele logica duidelijker en begrijpelijker wordt. Deze afgeplatte structuur verbetert niet alleen de leesbaarheid van de code, maar vermindert ook aanzienlijk de moeilijkheid van onderhoud.
• Deze optimalisatiemethode bereikt gecentraliseerd beheer van foutafhandelingslogica. Door onmiddellijk na elke conditiecontrole resultaten terug te geven, vermijden we onnodige code-uitvoering terwijl we de afhandeling van verschillende foutscenario's centraliseren, waardoor het gehele foutafhandelingsproces georganiseerder wordt.
• De kernlogica van de code—de voorwaarden voor het toestaan van toegang—wordt prominenter. Deze structuur maakt het hoofd doel van de code onmiddellijk duidelijk, wat de expressiviteit en begrijpelijkheid van de code aanzienlijk verbetert.

2. Tabelmethode opzoeken#

We komen vaak scenarios tegen waarin verschillende resultaten moeten worden teruggegeven op basis van verschillende invoer. Als deze niet goed worden afgehandeld, kunnen deze logica's gemakkelijk uitgroeien tot lange if-else ketens of massieve switch-instructies. Bijvoorbeeld, op een e-commerce platform moeten we corresponderende statusbeschrijvingen teruggeven op basis van verschillende bestelstatussen:

Dit is een typisch scenario van het teruggeven van verschillende resultaten op basis van verschillende gevallen. Naarmate het aantal gevallen toeneemt, wordt de switch-instructie of de if-else beoordelingen langer. Bovendien, in dit scenario, als gebruikers deze statusinhoud naar andere talen moeten vertalen, zou dit vereisen dat de functie-inhoud wordt gewijzigd of dat nieuwe functies worden toegevoegd, wat aanzienlijke onderhoudskosten met zich meebrengt.

In dit geval kunnen we de tabelmethode opzoeken om de code te optimaliseren:

Eerst, door een Map object te gebruiken om de mapping relatie tussen statussen en beschrijvingen op te slaan, wordt de code beknopter. We hebben ook de statusbeschrijvingen gemakkelijk verplaatsbaar naar configuratiebestanden gemaakt, wat gemak biedt voor internationalisatie en dynamische updates. Wanneer nieuwe statussen worden toegevoegd, hoeven we de kernlogica-code niet te wijzigen; we moeten alleen corresponderende sleutel-waardeparen in de configuratie toevoegen.

3. Interfacegerichte programmering#

Bij het ontwikkelen van grote softwaresystemen moeten we vaak meerdere serviceproviders of functionele modules ondersteunen. We kunnen overwegen om interfacegerichte programmering te gebruiken in de ontwerpfase van de software om latere uitbreidingen te vergemakkelijken en zo de complexiteit van meerdere conditionele beoordelingen, die ontstaat door hardcoding in complexe systemen, te elimineren.

Stel dat we een meertalige vertaalsysteem ontwikkelen dat verschillende vertaaldienstverleners moet ondersteunen. Als we niet vanaf het ontwerpproces interfacegerichte programmering overwegen, zullen latere uitbreidingen erg moeilijk worden:

Deze implementatie gebruikt een eenvoudige en botte if-else-structuur om vertaalproviders te selecteren, waardoor de code moeilijk te onderhouden en uit te breiden is. Wanneer in de toekomst nieuwe vertaaldiensten worden toegevoegd, moet de bestaande code worden gewijzigd, en naarmate meer vertaalproviders moeten worden ondersteund, zal de code opgeblazen en moeilijk te onderhouden worden. Tegelijkertijd is deze complexe methode ook moeilijk te unittesten omdat het niet eenvoudig is om verschillende vertaaldienstverleners te simuleren.

Om deze problemen op te lossen, kunnen we interfacegerichte programmering gebruiken om de code te optimaliseren. Interfacegerichte programmering is een belangrijke manier om polymorfisme te implementeren, waardoor verschillende objecten anders kunnen reageren op hetzelfde bericht.

Implementatieproces:

1. Definieer de vertaalstrategie interface:

2. Implementeer deze interface voor elke vertaalprovider:

3. Hervorm de TranslationService klasse, door de strategie als parameter door te geven:

4. Gebruik de geoptimaliseerde code:

Door de TranslationStrategy interface te definiëren en interfacegerichte programmering te introduceren, hebben we de volgende voordelen behaald:

• TranslationService kan verschillende vertaalstrategieën gebruiken voor elke oproep.
• Het toevoegen van nieuwe vertaalproviders wordt eenvoudig, maak gewoon een nieuwe strategieklasse aan en implementeer de interface.
• Clientcode kan flexibel de strategie kiezen die voor elke vertaling wordt gebruikt zonder de kernlogica van TranslationService te wijzigen.
• Elke vertaalstrategie kan onafhankelijk worden getest, wat de testbaarheid van de code verbetert.
• Het vermijden van toestandsbeheer in TranslationService maakt de service meer statusloos en thread-veilig.

Conclusie#

Het optimaliseren van de structuur van conditionele instructies is een belangrijk middel om de codekwaliteit te verbeteren. De drie methoden die in dit artikel geïntroduceerd zijn—defensief programmeren, tabelmethode opzoeken en interfacegerichte programmering (gecombineerd met polymorfisme)—hebben elk hun toepasselijke scenario's:

1. Defensief programmeren is geschikt voor het afhandelen van meerdere onafhankelijke conditiecontroles en kan effectief de codenesting verminderen.
2. De tabelmethode opzoeken is geschikt voor het afhandelen van vereisten die anders reageren op verschillende gevallen, waardoor de code beknopter en eenvoudiger te onderhouden is.
3. Interfacegerichte programmering gecombineerd met polymorfisme is geschikt voor het bouwen van complexe maar flexibele systemen, die de code flexibiliteit en schaalbaarheid verbeteren.

In de praktijk moeten we vaak op basis van specifieke situaties geschikte methoden kiezen, en soms zelfs meerdere technieken gezamenlijk toepassen. Het belangrijke is om een balans te vinden tussen de eenvoud, leesbaarheid en onderhoudbaarheid van de code, waarbij de oplossing wordt gekozen die het beste past bij het huidige probleem.

Onthoud, over-optimisatie kan tijdens leiden tot te complexe code. Het houden van de code simpel en leesbaar is altijd het primaire principe. Bij het toepassen van deze technieken moeten wijs keuzes worden gemaakt op basis van de specifieke behoeften van het project en het technische niveau van het team.