Negare l'istanziazione!!

[Mezzetti0903]

Negare l'istanziazione!! Preferibilmente in C#

Mi potete fare un esempio in qualsisasi linguaggio di come potrebbe essere possibile, se mai è possibile, negare l'instanziazione da costruttore?? ES(un po' cialtrone perchè lo faccio sul momento):

public class Servizi
public Servizi(string username,string password) {
if ((username=="CIAO") && (password=="CIAO")) {
// OK TUTTO A POSTO
}
else { // ANNULLA L'ISTANZA }
}
}
Ora.. potrei che ne so mettere una variabile "isaccessible" = false
che viene controllata da TUTTI i metodi e propietà prima che si eseguino ma..NON MI SEMBRA ELEGANTE
non mi sembra nè

[/\/\@®¢Ø]

Originally posted by "Mezzetti0903"

Negare l'istanziazione!! Preferibilmente in C#

Mi potete fare un esempio in qualsisasi linguaggio di come potrebbe essere possibile, se mai è possibile, negare l'instanziazione da costruttore?? ES(un po' cialtrone perchè lo faccio sul momento):

public class Servizi
public Servizi(string username,string password) {
if ((username=="CIAO") && (password=="CIAO")) {
// OK TUTTO A POSTO
}
else { // ANNULLA L'ISTANZA }
}
}
Ora.. potrei che ne so mettere una variabile "isaccessible" = false
che viene controllata da TUTTI i metodi e propietà prima che si eseguino ma..NON MI SEMBRA ELEGANTE
non mi sembra nè

Una soluzione potrebbe essere quella di gettare un'eccezione nel costruttore:

public class Servizi
   public Servizi(string username,string password) {
         if ((username=="CIAO") && (password=="CIAO")) {
               // OK TUTTO A POSTO
         }
         else { 
		throw Error("blablalba");
	}
   }

nel codice poi faresti cosi'

...
try {
	x = new Servizi("pinco","pallino");
} catch( Error e )
{
...
}

ovviamente al netto degli errori . Conosco poco il C# e quindi non so se supporta le eccezioni nel costruttore, devi comunque stare attento che non e' mai una bella cosa cominciare un lavoro (costruire un oggetto) e poi lasciarlo a meta' (lanciando l'eccezione). Prima di lanciare l'eccezione provvedi a "ripulire" quanto fatto, ad esempio liberando risorse se queste non verranno sistemate automaticamente dal garbage-collector.
Una alternativa e' fare una classe apposita che costruisca (o meno) l'oggetto di cui hai bisogno:

public class ServiceFactory
{
	public Servizi getService( string username, string password )
	{
		...
	}
}

che ritorna un oggetto se i parametri sono corretti, un null altrimenti. La cosa si puo' anche estendere: in questo caso infatti il vero oggetto ritornato non e' noto, potrebbe essere una sottoclasse di Servizi, e si potrebbe ritornare un oggetto con diritti particolari in base all'utente.

[kingv]

non conosco C#, ma in Java puoi farlo creando SOLO un costruttore senza argomenti e dichiarandolo private.

[cionci]

Vuoi che ci sia una sola istanza di quella classe in memoria ?

[cn73]

In java esiste la classe IllegalArgumentException()...come ti hanno suggerito puoi lanciare un eccezione, ma non generica!

throw new IllegalArgumentException("tuo messaggio");

is very elegant

[kingv]

Originally posted by "cn73"

In java esiste la classe IllegalArgumentException()...come ti hanno suggerito puoi lanciare un eccezione, ma non generica!

throw new IllegalArgumentException("tuo messaggio");

is very elegant

son punti di vista ma per me lanciare sempre un'eccezione in un costruttore per non fare istanziare un oggetto e' dal punto di vista del design e' orrido, non elegante.

Un'eccezione (come dice il nome) serve a notificare al chiamante che si e' verificato un problema (infrastruturale, NON applicativo) su una chiamata. E' l'intefaccia che fornisci che deve condizionare la chiamata, non un'eccezione!
Se vuoi condizionare l'istanziazione di un oggetto esiste un patter chiamato factory (con decine di varianti) che fa al caso tuo.

tutto IMHO, naturalmente ig:

[cionci]

Se io la facessi in C++ farei così...ma funziona grazie ai puntatori...

class Servizi {
   Servizi() { /*costruttore di default*/ }; //privato, non richiamabile direttamente
public:
   static Servizi* Autentifica(string user, string pass); //deve essere static
};

Servizi* Servizi::Autentifica(string user, string pass)
{
   if(user == "ciao" && pass == "ciao")
      return new Servizi;
   else
      return NULL;
}

//Si usa in questo modo:

Servizi *s = Servizi::Autentifica("pippo", "pluto");
if(s)
  //allocato
else
  //non allocato

Questo metodo è derivato abbastanza direttamente dal design-pattern "Singleton"....

http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=486

[cionci]

Aggiungo che anche secondo me usare un'eccezione è come ammazzare una mosca con una cannonata...senza contare che è stilisticamente brutto...ma brutto brutto brutto...

[Mezzetti0903]

Innanzi tutto Grazie a tutti....
L'idea di lanciare l'eccezione è funzionale ma certo.. come dice Cionci... brutta brutta brutta....
Ecco invece è una buona idea l'ultima di /\/\@®¢Ø.... penso che farò così!!

Originally posted by "/\/\@®¢Ø"



Una alternativa e' fare una classe apposita che costruisca (o meno) l'oggetto di cui hai bisogno:

public class ServiceFactory
{
	public Servizi getService( string username, string password )
	{
		...
	}
}

che ritorna un oggetto se i parametri sono corretti, un null altrimenti. La cosa si puo' anche estendere: in questo caso infatti il vero oggetto ritornato non e' noto, potrebbe essere una sottoclasse di Servizi, e si potrebbe ritornare un oggetto con diritti particolari in base all'utente.

Grazie a tutti ancora

[Tassadar]

puoi anche, come diceva kingv, usare un metodo statico per avere l'istanza della classe che ti interessa e dichiarare il costruttore privato:

public class Servizi{
  private Servizi(){
    super(); //costruttore ereditato da Object
  }

  public static Servizi getServizi(string username,string password) {
    if ((username=="CIAO") && (password=="CIAO")) {
      return new Servizi();
    }
    else {
      return null; //oppure throw new IllegalArgumentException("blah blah blah");
    }
  }
}

[cionci]

Originally posted by "Tassadar"

puoi anche, come diceva kingv, usare un metodo statico per avere l'istanza della classe che ti interessa e dichiarare il costruttore privato:

public class Servizi{
  private Servizi(){
    super(); //costruttore ereditato da Object
  }

  public static Servizi getServizi(string username,string password) {
    if ((username=="CIAO") && (password=="CIAO")) {
      return new Servizi();
    }
    else {
      return null; //oppure throw new IllegalArgumentException("blah blah blah");
    }
  }
}

Che è la stessa cosa di quelo che io ho fatto in C++...

[Tassadar]

esatto
Ciao defender

[Mezzetti0903]

..anche :-))

Forse è anzi più chiaro e razionale con il metodo statico...

Grazie ancora :-D

[/\/\@®¢Ø]

Originally posted by "kingv"


Un'eccezione (come dice il nome) serve a notificare al chiamante che si e' verificato un problema (infrastruturale, NON applicativo) su una chiamata.

Ma questo non ha a che fare col fatto che sia gettata in un costruttore o in un metodo.
Oltretutto l'eccezione (come dice il nome ) e' semplicemente qualcosa che accade non troppo spesso, e che quindi e' scomodo dover gestire singolarmente, oppure quando avviene non si hanno informazioni sul come comportarsi. Nel caso in oggetto serve poco perche' presumibilmente il login avviene in un solo punto e quindi ha poco senso sostituire un controllo if con un try{...}catch nello stesso punto. Se pero' l'eccezione rientra in una categoria piu' generica di eccezioni si puo' comunque utilizzarla, raccogliendola molto piu' a monte per fare un repulisti con la ramazza e chiudere il tutto il contesto in cui ci si trova (che non e' necessariamente l'applicazione intera).

E' l'intefaccia che fornisci che deve condizionare la chiamata, non un'eccezione!

Non sono d'accordo. Dipende dallo "schema generale", visto anche che l'eccezione serve appunto per spostarsi dal contesto locale.

Se vuoi condizionare l'istanziazione di un oggetto esiste un patter chiamato factory (con decine di varianti) che fa al caso tuo.

Che e' il secondo esempio che ho fatto
Comunque non e' necessariamente detto che le factory siano la cosa migliore, perlomeno se il solo scopo e' controllare i parametri. In fondo un wrapper attorno al costruttore non e' poi molto differente da un try-catch , e scrivi pure piu' codice.

[kingv]

Originally posted by "/\/\@®¢Ø"


Ma questo non ha a che fare col fatto che sia gettata in un costruttore o in un metodo.
Oltretutto l'eccezione (come dice il nome ) e' semplicemente qualcosa che accade non troppo spesso, e che quindi e' scomodo dover gestire singolarmente, oppure quando avviene non si hanno informazioni sul come comportarsi. Nel caso in oggetto serve poco perche' presumibilmente il login avviene in un solo punto e quindi ha poco senso sostituire un controllo if con un try{...}catch nello stesso punto. Se pero' l'eccezione rientra in una categoria piu' generica di eccezioni si puo' comunque utilizzarla, raccogliendola molto piu' a monte per fare un repulisti con la ramazza e chiudere il tutto il contesto in cui ci si trova (che non e' necessariamente l'applicazione intera).

piu' che un qualcosa che accade raramente l'eccezione dovrebbe essere qualcosa che NON dovrebbe accadere in situazioni standard.
mettiamo che tu abbia un'applicazione che controlla il saldo di conto corrente perche' deve fare un bonifico. Se la comunicazione appc (o qualsiasi altra cosa usi per collegarti ad host) crasha ( fortuna che non faccio il prof di italiano) allora il lancio di una eccezione ad hoc puo' essere giustificato, in modo che nella catena dele chiamate si possa far pulizia e poi abortire la transazione. ma se ti viene risposto che il saldo di cc e' negativo (e quindi il bonifico non lo puoi fare) lanciare una NoTieneDineroException ( ) e' una ca**ata dal punto di vista del design, perche' questa e' una condizione applicativa che sara' anche rara ma deve essere gestita dal flusso del'applicazione, non deve stravolgerlo.

Originally posted by "/\/\@®¢Ø"



Non sono d'accordo. Dipende dallo "schema generale", visto anche che l'eccezione serve appunto per spostarsi dal contesto locale.

come sopra, perche' lanciare un'eccezione quando puoi scrivere "return false"?

Originally posted by "/\/\@®¢Ø"



Che e' il secondo esempio che ho fatto
Comunque non e' necessariamente detto che le factory siano la cosa migliore, perlomeno se il solo scopo e' controllare i parametri. In fondo un wrapper attorno al costruttore non e' poi molto differente da un try-catch , e scrivi pure piu' codice.

a me il problema non sembrava controllare i parametri (anche nel costruttore puoi farlo, non occorre una factory) ma impedire (o limitare) l'istanziazione di un oggetto :o

[cn73]

Lanciare un'eccezione non è affatto brutto, brutto, brutto, brutto... ne tantomeno poco "stilistico". Esiste fior di letterautura su come creare classi di eccezione ad arte per adattarsi agli scopi funzionali.

Allora tanto vale per risolvere il problema del nostro amico controllare a priori, prima di istanziare l'oggetto, che i parametri siano accettabili.

Naturalmente IMHO

[/\/\@®¢Ø]

Originally posted by "kingv"


piu' che un qualcosa che accade raramente l'eccezione dovrebbe essere qualcosa che NON dovrebbe accadere in situazioni standard.

Mi sa che intendiamo la stessa cosa .
Come dicevo sompra l'eccezione e' comoda e giustificata se posso lanciarla in molte parti e raccoglierla in una ( o poche ) cosi' che il codice "in mezzo" puo' fregarsene, a vantaggio della leggibilita'. Un esempio e' quello che fai tu, ma non e' comunque un concetto piu' generale

come sopra, perche' lanciare un'eccezione quando puoi scrivere "return false"?

Il problema non e' il codice che si deve scrivere per segnalare un errore, ma quello per trattarlo ! Se poi devo scrivere cinquanta volte
if ( x != null ){ ... } else { ... } l'eccezione puo' essere una buona soluzione, perlomeno se mi e' permesso gestirla "non in loco" ( ovvero sostituire i suddetti if con altrettanti blocchi "try" non e' la soluzione che propongo io )

a me il problema non sembrava controllare i parametri (anche nel costruttore puoi farlo, non occorre una factory) ma impedire (o limitare) l'istanziazione di un oggetto :o

Mi sono espresso male comunque la sostanza del mio discorso resta invariata

[kingv]

Originally posted by "/\/\@®¢Ø"



8< 8< 8< 8<

Mi sono espresso male comunque la sostanza del mio discorso resta invariata

ho riletto il primo post di Mezzetti, sono io che non ho capito 'na ma**a, non avevo letto il codice :o :o :o



comunque la sostanza del mio discorso resta invariata ig:

[cionci]

Originally posted by "cn73"

Lanciare un'eccezione non è affatto brutto, brutto, brutto, brutto... ne tantomeno poco "stilistico". Esiste fior di letterautura su come creare classi di eccezione ad arte per adattarsi agli scopi funzionali.

Non è il fatto di crearsi classi di eccezione che non deve essere fatto, ma usare l'eccezione per riportare un evento che può essere tranquillamente gestito a livello di codice normale...
Sono d'accordo con kingv...l'eccezione deve essere qualcosa che deve rispecchiare un'anomalia nell'esecuzione del flusso abituale del programma... Un'autentificazione non riuscita non mi sembra affatto un fatto anomalo...

Originally posted by "cn73"

Allora tanto vale per risolvere il problema del nostro amico controllare a priori, prima di istanziare l'oggetto, che i parametri siano accettabili.

Infatti è ciò che viene fatto con il metodo static... Il controllo viene effettuato prima di istanziare l'oggetto...
Perchè non faro al di fuori dell'oggetto ? Beh...dipende dal contesto... Se l'autentificazione è logicamente parte integrante dell'oggetto (ad esempio mettiamo che sia una classe di interfacciamento con un DB e che l'autentificazione sia in questo caso la connessione al DB) allora mi sembra logico che il metodo da adottare sia quello postato (soprattutto per poter riusare al meglio la classe)...

[dm69]

Secondo me le eccezioni dovrebbero essere usate sempre per gestire qualunque situazione non nominale.
Nel caso in questione si chiedeva di negare la creazione di un oggetto qualora non fossero verificate certe condizioni. Se il costruttore lanciasse una eccezione, il ramo di codice che doveva usare l'eventuale oggetto viene terminato senza dover fare alcun check del tipo:
if (p!=NULL)
....
else
...

In programmi di grande dimensione si risparmia una gran quantita' di codice di error handling. Inoltre, spesso, ci si dimentica di fare questo tipo di check e a run time possiamo avere dei crash inattesi.
In questo caso (se si usasse il C++), inoltre, usando l'eccezione possiamo anche evitare l'allocazione dinamica dell'oggetto (che spesso ci si dimentica di deallocare). Infatti non essendo abbligati a tornare un NULL per dire che la creazione e' fallita, possiamo usare l'oggetto come un tipo qualunque:

....
Servizi servizio(user, passwd);
.... // qui' ci arriviamo sole se il check e' superato.


Ciao a tutti.