[*] Forme per definizione procedure analoghe con parametri differenti

[pietro09]

Mi scuso per il titolo. Quello che chiedo è indipendente dal linguaggio ed è molto generale.
Tanto per andare sul concreto, supponiamo di avere un metodo :

public static void ImgSaveToFile(Bitmap bmp, string immagineOutput, FormatoOutput formatoOutput, int compressione)

questo metodo ha il compito di salvare una immagine su disco; i parametri sono:

bmp -> l'immagine da salvare
immagineOutput -> nome file su cui salvare
FormatoOutput -> formato dell'immagine salvata: gif, jpg, png, ...
compressione -> in caso di jpg, compressione da 0 a 100

Dunque, il mio dubbio è l'ultimo parametro che serve solo se il precedente è tipo jpg

Vi chiedo come si risolvono in generale queste situazioni
:master: Forse con due procedure separate? :master:
ciao

[zucchino]

purtroppo la risposta è invece di dipendente dal linguaggio.

in C++ puoi ad esempio usare gli argomenti di default:

dichiarando la funzione in questo modo:

public static void ImgSaveToFile(Bitmap bmp, string immagineOutput, FormatoOutput formatoOutput, int compressione = 0);

così la funzione puo' essere chiamata nei due modi.

ImgSaveToFile(bmp, immagineOutput, formatoOutput);
ImgSaveToFile(bmp, immagineOutput, formatoOutput, compressione);

ovviamente devi controllare che l'utilizzatore non faccia porcate, nessuno gli vieta di passarti formatoOutput==JPEG ma senza compressione.

[pietro09]

Originariamente inviato da zucchino
purtroppo la risposta è invece di dipendente dal linguaggio.

in C++ puoi ad esempio usare gli argomenti di default:

dichiarando la funzione in questo modo:

public static void ImgSaveToFile(Bitmap bmp, string immagineOutput, FormatoOutput formatoOutput, int compressione = 0);

così la funzione puo' essere chiamata nei due modi.

ImgSaveToFile(bmp, immagineOutput, formatoOutput);
ImgSaveToFile(bmp, immagineOutput, formatoOutput, compressione);

ovviamente devi controllare che l'utilizzatore non faccia porcate, nessuno gli vieta di passarti formatoOutput==JPEG ma senza compressione.

Ti ringrazio della risposta. Attualmente, in attesa di escogitare qualcosa di meglio, uso esattamente due versioni in overload con le firme uguali al tuo suggerimento. Quando l'utente sceglie la firma senza compressione ma sceglie il formato jpg, ovviamente imposto una compressione predefinita.
Ciao

[alka]

Originariamente inviato da pietro09
Quello che chiedo è indipendente dal linguaggio ed è molto generale.

Sicuramente tu ne farai uso in un linguaggio specifico, quindi la tua richiesta generica è "sibillina" e mi fa pensare che sia posta in termini così assoluti solo per avere una maggiore garanzia di risposta, quando poi la sua applicabilità non è certa per il linguaggio che ti troverai ad utilizzare, che posso ipotizzare (dalle tue passate discussioni) che sia C# o VB.NET.

Sono del tutto certo che qualsiasi risposta inerente C++, Java, Delphi o altro non ti avrebbe soddisfatto, quindi perché non orientarsi direttamente ai linguaggi che ti interessano, soprattutto quando non sei certo che una certa "caratteristica" appartenga al tuo linguaggio oppure no?

In breve, suggerisco di porre domande language independent solo quando si è intimamente certi che lo siano, non quando poi - ottenute risposte generali - si vorrebbe applicarne quanto detto ad un linguaggio ben specifico.

Questo come linea di direttiva generale, tanto per evitare incomprensioni o confusione.

Ciao!

[pietro09]

Gentilissimo alka, ho letto con attenzione la tua gradita risposta. Cerco di spiegare bene il problema.
Cerco di farmi, in vb.net e in c#, una serie di procedure per manipolare le immagini: leggerle, ridimensionarle, salvarle.
Alla fine mi accorgo che il problema non sta nelle procedure ma nella loro struttura.
Per esempio, la procedura ImgSave, mi salvava l'immagine su disco o sullo stream di uscita, solo in base ad un argomento immagineOutput:

se è una stringa vuota allora salva su stream uscita, altrimenti salva sul file indicato.

Questo è già indipendente dai due linguaggi citati, dato che, chiunque mi potrebbe suggerire di separare quella procedura in due procedure specializzate, SalvaSuFile e SalvaSuStream

Per cui adesso mi ci trovo con una procedura che ha bisogno di un parametro solo se l'utilizzatore utilizza un particolare valore del parametro precedente.
Questo per me è un campanello di allarme che mi dice semplicemente che ho progettato male tale procedura.

Allora, sempre restando sul generale, mi piacerebbe che mi si dicesse, per esempio:
sì, il problema è noto ed è stato affrontato in c++ così, in Pascal così, non è stato risolto in c#, oppure: hai progettato male la procedura; prova a scinderla in due con compiti diversi

Ciao

[alka]

Originariamente inviato da pietro09
Cerco di farmi, in vb.net e in c#, una serie di procedure per manipolare le immagini: leggerle, ridimensionarle, salvarle.
Alla fine mi accorgo che il problema non sta nelle procedure ma nella loro struttura.
Per esempio, la procedura ImgSave, mi salvava l'immagine su disco o sullo stream di uscita, solo in base ad un argomento immagineOutput

In questo caso specifico, non penso ci sia un difetto di progettazione, visto che l'esigenza che poni è un normalissimo problema che si affronta quotidianamente.

Dal mio punto di vista, hai due soluzioni: potresti semplicemente creare due procedure con nome diverso che espliciti il diverso "media" di destinazione, oppure sfruttare l'overloading di funzioni, se presente nel linguaggio adottato.

Esemplificando, potresti creare due metodi ImgSaveToFile e ImgSaveToStream che accettino parametri differenti in base al mezzo in cui salvare, oppure creare due funzioni con lo stesso nome che abbiano parametri differenti, uno il percorso del file in cui salvare, l'altro il riferimento all'oggetto "stream" che deve ottenere l'immagine, se il linguaggio supporta l'overloading.

In generale, io non sono un maniaco dell'overloading, che uso solo in ambiti specifici; ad esempio, non sopporto quei casi, frequenti nella FCL del .NET Framework, in cui uno stesso metodo può comportarsi in modi radicalmente differenti, tutti raggruppati in metodi con lo stesso nome, decine di versioni diverse dello stesso nome di metodo in overload: sarebbe quasi più comodo averne uno specifico per ogni esigenza, così da consentire all'IDE di suggerire solamente quei parametri che sono propri dell'implementazione che si vuole utilizzare.

Concludendo, la risoluzione al tuo problema si ottiene, secondo me, con una delle due metodologie indicate. Mentre la prima è possibile in qualsiasi linguaggio, anche in forme analoghe ad un metodo (es. procedura), la seconda vale solo in quei linguaggi che supportano l'overloading, tra cui C# e VB.NET che sono quelli che utilizzi, e tantissimi altri (Delphi, C++, ecc.).

Ciao!

[pietro09]

Le tue argomentazioni le condivido appieno e in effetti è quella la strada che ho percorso: quando le procedure fanno operazioni molto diverse, divido i compiti in procedure specializzate, ed utilizzo l'overloading con parsimonia dove ragionevolmente aiutano l'utilizzatore.
Ciao