Best practice functie variaties

[cyspoz]

Ik zou graag wat meningen willen horen van andere mensen. Stel je voor je hebt een aantal functies. Van iedere functie zijn vaste mogelijke varianten alleen verschilt het welke ondersteund worden. Maak je hiervoor meerdere functies aan (Oplossing 1) of geef je een parameter mee (Oplossing 2) waarin je het afwijkende gedrag van de functie aangeeft.

Oplossing 1:

code:

FunctionA_var1();
FunctionA_var2();
FunctionA_var3();

FunctionB_var1();
FunctionB_var3();

Oplossing 2:

code:

FunctionA(Var functionVar); // Ondersteund variatie 1, 2 & 3
FunctionB(Var functionVar); // Ondersteund variatie 1 & 3

Het nadeel van oplossing 1 is dat het mogelijk code duplicatie in die hand werkt en een hoop overhead kan veroorzaken in de documentatie.
Het nadeel van oplossing 2 vind ik dat je als gebruiker van de code niet meteen kan zien welke variaties er ondersteund worden en je dat dus eerst zal moeten opzoeken in de code. Een ander nadeel is dat de code in je functie iets minder duidelijk wordt door het opnemen van de variaties.

[ Voor 3% gewijzigd door cyspoz op 20-04-2007 14:21 ]

[TeeDee]

Wat is er mis met bijvoorbeeld:

C#:

void MethodName(string melp)
{
MethodName(melp,null,null)
}

void MethodName(string melp, int woei)
{
MethodName(melp,woei,null)
}

void MethodName(string melp, int woei, bool blaat)
{ 
//voer een en dezelfde method uit...
}

even pseudo...een collega had een leuke benaming hiervoor: "shit goes down the ladder". Zoiets

Het nadeel van oplossing 2 vind ik dat je als gebruiker van de code niet meteen kan zien welke variaties er ondersteund worden en je dat dus eerst zal moeten opzoeken in de code. Een ander nadeel is dat de code in je functie iets minder duidelijk wordt door het opnemen van de variaties.

Als gebruiker hoef je dat ook niet te zien. Een goede documentatie zou voldoende moeten zijn, tevens kan een goede IDE met bijv. Intellisense een hele hoop uit handen nemen. Daar zie je bijvoorbeeld alleen MethodName, met daarbij 2 of meer Overloads.

[cyspoz]

Hahaha op zich wel een leuke benaming, maar dit is niet precies wat ik bedoel. Ik heb een aantal functies die hun werk kunnen doen zonder parameter. Alleen wat ze inhoudelijk doen kan variëren, echter de return waarde is ook altijd hetzelfde. De mogelijke variaties liggen dus vast, alleen niet iedere functie ondersteund alle variaties. In mijn Oplossing 2 zou dus functionVar een waarde hebben van 1, 2 of 3 om aan te geven welke variatie uitgevoerd moet worden. Echter ondersteund het dus bijvoorbeeld niet variatie 2.

[ Voor 21% gewijzigd door cyspoz op 20-04-2007 14:21 ]

[cspare]

Ik denk dat het een beetje van de situatie afhangt, maar oplossing 2 vind ik wel de mindere.
Als de code een beetje modulair is zou je per branche (vertakking:x) een private methode kunnen maken, dan heb je in iedergeval geen dubbele code.

Wat netheid betreft zou ik liever voor oplossing 1 gaan, zolang je zinvolle namen specificeerd.

[rrrandy]

Ik snap het nadeel van oplossing twee niet helemaal

Volgens mij hebben ze daar commentaar voor uitgevonden

[cyspoz]

Nadeel van oplossing 2 is dat het pas runtime naar voren komt, terwijl bij oplossing 1 alles compile time wordt afgedwongen. Laatste heeft volgens mij toch wel de voorkeur.

[Confusion]

cyspoz schreef op vrijdag 20 april 2007 @ 14:19:
Hahaha op zich wel een leuke benaming, maar dit is niet precies wat ik bedoel. Ik heb een aantal functies die hun werk kunnen doen zonder parameter. Alleen wat ze inhoudelijk doen kan variëren, echter de return waarde is ook altijd hetzelfde. De mogelijke variaties liggen dus vast, alleen niet iedere functie ondersteund alle variaties. In mijn Oplossing 2 zou dus functionVar een waarde hebben van 1, 2 of 3 om aan te geven welke variatie uitgevoerd moet worden. Echter ondersteund het dus bijvoorbeeld niet variatie 2.

Dit moet je niet met meerdere functies oplossen, die alleen qua naam met elkaar samenhangen. Dit is het moment waarop overgaan op object georienteerd programmeren verstandig is, om overzichtelijkheid en code duplicatie te bewaren. Het Template pattern en het Factory pattern zouden weleens nuttig kunnen zijn, afhankelijk van het precieze probleem.

[TeeDee]

Confusion schreef op vrijdag 20 april 2007 @ 15:10:
[...]

Dit moet je niet met meerdere functies oplossen, die alleen qua naam met elkaar samenhangen. Dit is het moment waarop overgaan op object georienteerd programmeren verstandig is, om overzichtelijkheid en code duplicatie te bewaren. Het Template pattern en het Factory pattern zouden weleens nuttig kunnen zijn, afhankelijk van het precieze probleem.

Compleet mee eens!

[cyspoz]

Misschien handig als ik iets meer context geef. Het gaat om functies die data genereren. Je zou dus zoiets kunnen krijgen:

code:

string GenerateDataTypeAMin();
string GenerateDataTypeAMax();
string GenerateDataTypeARandom();

string GenerateDataTypeBMin();
string GenerateDataTypeBRandom();

Ik begrijp alleen even niet wat OO hiermee kan helpen.

[Verwijderd]

Indien de variaties bepaald worden doormiddel van verschillende parameters (dus benodigde invoer), zou ik 'overloading' gebruiken.

Indien de functie een iets ander gedrag vertoont (bv. een msgdialog , die de ene keer een warning geeft en de andere keer een error) kan het eventueel door parameters.

Anderzijds als de variatie tussen functie_var1 en functie_var2 nogal groot is, moet je misschien toch denken over betere naamgeving.


btw. Ik vind je voorbeelden nogal vrij abstract voor de vraagstelling.
[edit]
had ff op F5 moeten duwen

Het enige wat die functies overeen hebben is dat ze een getal teruggeven, ik zou ze lekker apart houden doormiddel van naamgeving.
Of je stopt ze in een 'GenereerGetal' class waarin je weer de verschillende methods aanroept.

Maak van die datatypes een class waarin je de Min,Max,Random methods implementeerd.

[ Voor 25% gewijzigd door Verwijderd op 20-04-2007 15:25 ]

[rrrandy]

cyspoz schreef op vrijdag 20 april 2007 @ 15:06:
Nadeel van oplossing 2 is dat het pas runtime naar voren komt, terwijl bij oplossing 1 alles compile time wordt afgedwongen. Laatste heeft volgens mij toch wel de voorkeur.

Misschien was ik niet helemaal duidelijk, het gaat mij er meer om wat de topic starter als nadeel naar voren brengt. Dat het voor andere programmeurs niet duidelijk is wat de functies zelf doen.

[cyspoz]

Verwijderd schreef op vrijdag 20 april 2007 @ 15:21:
Maak van die datatypes een class waarin je de Min,Max,Random methods implementeerd.

Jaaaa, dat is nog eens een idee waar ik warm van loop. Is denk ik inderdaad een erg nette oplossing.

[Remus]

cyspoz schreef op vrijdag 20 april 2007 @ 15:16:
Misschien handig als ik iets meer context geef. Het gaat om functies die data genereren. Je zou dus zoiets kunnen krijgen:

code:

string GenerateDataTypeAMin();
string GenerateDataTypeAMax();
string GenerateDataTypeARandom();

string GenerateDataTypeBMin();
string GenerateDataTypeBRandom();

Ik begrijp alleen even niet wat OO hiermee kan helpen.

Wat OO hiermee te maken kan hebben, is dat je door middel van het Strategy (of Template Method) pattern een abstract object zou kunnen definieren voor alleen deze methode (of een groep gerelateerde methodes), met bijbehorende implementaties en door middel van een Factory of Abstract Factory de juiste implementatie runtime kunt kiezen. Het voordeel is dus dat de variatie in implementie en de regels voor het instantieren van de methode niet liggen bij het gebruikende object (dit zorgt er ook nog eens voor dat dit makkelijker te onderhouden is).