In urma cu cateva saptamani am discutat putin despre keyword-ul params si cautam locuri unde acesta ar putea sa fie folosit cu un scop clar, nu doar de dragul de a il folosi. Zilele acestea am gasit un caz unde acesta ar putea sa isi gaseasca locul.
Sa presupunem ca scriem o metoda care genereaza semnatura unei metode pe baza. Numarul de parametrii a unei metode poate sa fie variat de la 1 la n si chiar 0. Din aceasta cauza pentru a putea sa acoperim cele doua cazuri ar fi nevoie sa avem ca si parametru o colectie de parametri care sa accepte sa fie si null.
Cum vi se pare acest caz? Credeti ca in acest caz este folositor "params"?
Sa presupunem ca scriem o metoda care genereaza semnatura unei metode pe baza. Numarul de parametrii a unei metode poate sa fie variat de la 1 la n si chiar 0. Din aceasta cauza pentru a putea sa acoperim cele doua cazuri ar fi nevoie sa avem ca si parametru o colectie de parametri care sa accepte sa fie si null.
public string GetMethodSignature(string methodName, List<object> parameters = null)
Acuma apar usoare probleme pentru cel care ne foloseste metoda. Pentru fiecare apel cand are unul sau mai multi parametri o sa fie nevoit sa creeze o lista de elemente.myObj.GetMethodSignature( "FooAction" , new [] { param1 });
In acest caz, o implementare folosind params ne simplifica putin atat apelul cat si modul in care procesam datele:public string GetMethodSignature(string methodName, params object[] parameters)
...
myObj.GetMethodSignature( "FooAction" , param1 );
myObj.GetMethodSignature( "FooActionNoParam");
Pentru cazul cand nu avem nici un parametru este de ajuns sa apelam metoda ca si mai sus, iar colectia noastra nu o sa aibe nici un element.Cum vi se pare acest caz? Credeti ca in acest caz este folositor "params"?
Depinde ce se intelege prin "metoda care genereaza semnatura unei metode pe baza" - daca e vorba de metode overloaded, acestea pot diferi nu doar prin numarul si numele parametrilor, ci si prin tipul lor - deci pot exista doua metode:
ReplyDeleteFooAction(int a);
FooAction(DateTime a);
Altfel, varianta cu params e doar un mic sintactic sugar care usureaza munca programatorului - mai important mi se pare ca
List parameters
e destul de vag si nu sugereaza ce ar trebui pasat acolo fara a citi ceva documentatie/comments..
In plus, daca in viitor cineva va vrea intr-o clasa derivata sa adauge un parametru intr-un overload al metodei respective, de genul:
public string GetMethodSignature(string methodName, int newParam, params obj ect[] parameters)
poate introduce un breaking change in codul existent.
Deci as evita params intr-un framework/API public, dar no problems in interiorul unei aplicatii..
Pe partea de breaking change in codul existent e un risc destul de mare daca expui o metoda in API ce foloseste params.
DeleteParams in sine e un sintactic sugar, eu incercam sa vad poate sa fie util cu adevarat.
parameters ar putea sa fie redenumit parametersMethodValue, poate asa ar fi mai usor de inteles ce reprezinta.