[C++] Oggetto con dentro oggetto: come fare per..?

[luxorl]

Ciao, ho un oggetto client creato da me che dentro ha due oggetti socket_client anche essi creati da me.

Ho letto che devo inserire i costruttori degli oggetti interni nel costruttore dell'oggetto che li contiene.

Però io vorrei ottenere i parametri per inizializzare gli oggetti interni da console in un secondo momento.

Qual è il giusto modo di procedere?

[cionci]

Intendi dire che hai definito due classi internamente ad un'altra ?

Fosse questo il caso, allora ti basta definire un factory method, ovvero metti il costruttore privato alla classe client e crei un metodo statico nella classe client che ritorna un oggetto di tipo client. Al metodo static passi i parametri presi da riga di comando e all'interno crei i due oggetti socket_client e poi li passi al costruttore.

[luxorl]

Originariamente inviato da cionci

Intendi dire che hai definito due classi internamente ad un'altra ?

Fosse questo il caso, allora ti basta definire un factory method, ovvero metti il costruttore privato alla classe client e crei un metodo statico nella classe client che ritorna un oggetto di tipo client. Al metodo static passi i parametri presi da riga di comando e all'interno crei i due oggetti socket_client e poi li passi al costruttore.

No, io ho definito l'oggetto socket_client in un file a parte.
Poi dentro la classe client mi dichiaro due attributi:

socket_client sc1;
socket_client sc2;

Quando da un main creo l'oggetto client vorrei non dover conoscere a priori i parametri (ip e porta) per instanziare gli oggetti sc1 e sc2.

In particolare l'ip e la porta di sc1 la prendo da console, mentre l'ip e la porta di sc2 è calcolata internamente al sistema in base alla richiesta che farà il client.

[cionci]

Allora glielo devi passare in qualche modo dopo, ma secondo me denota che c'è qualcosa che non va nel tuo design.

[luxorl]

Originariamente inviato da cionci

Allora glielo devi passare in qualche modo dopo, ma secondo me denota che c'è qualcosa che non va nel tuo design.

Ma il compilatore non si arrabbia se non metto il costruttore degli oggetti interni nel costruttore dell'oggetto che li contiene?

Tu dici che è un modo sbagliato di progettare il sistema? E' la prima volta che programmo in c++, in Java ho sempre usato questo stile ottenendo buoni risultati.

Come suggeriresti di procedere? Io ho scelto di metterli come attributi della classe per farli vedere a tutti i metodi di client. Secondo te è meglio che i metodi si passino fra di loro i socket_client?

[cionci]

Difficile da dire...
Ovviamente dovrai metterli come puntatori inizializzati a NULL e dovrai allocarli nel momento in cui passerai ad un metodo della classe i vari dati necessari per l'allocazione.
Per la deallocazione ci penserai nel distruttore.

[Ikon O'Cluster]

Io nella classe Client metterei 2 puntatori, anzi un array di N elementi puntatore che puoi chiamare ad esempio socketClientArray e dove nel tuo caso N=2. In questo modo N può essere anche diverso da 2. I puntatori saranno puntatori ad oggetti di tipo socket_client. A quel punto creerei una funzione tipo bool setSocketClient(int argc, char* argv[]) la quale permette di avvalorare i puntatori privati che stanno dentro Client. Inoltre dentro la classe client manterrei una variabile unsigned char numSocketClient inizializzata a 0. In questo modo le istanze di socket_client le crei solo all'occorrenza e ogni volta che la crei fai:

setSocketClient(argc, argv);

dove la funzione farà qualcosa tipo:

bool setSocketClient(int argc, char* argv[]) {
if(numSocketClient deve essere >= N) return false;
socketClientArray[numSocketClient++] = new socket_client(argc, argv);
return true;
}

Avere numSocketClient ti permette di sapere se i puntatori sono inizializzati. In questo modo che le funzioni membro di Client prima di fare operazioni possono fare un controllo su numSocketClient ed eventualmente restituire un errore.

Ovviamente devi fare molta attenzione perchè non hai il garbage collector, quindi dato che i socket_client devono morire insieme a Client, nel distruttore di Client devi fare la deallocazione:

for(int i=0; i<numSocketClient; i++) {
delete socketClientArray[numSocketClient--];
}

E se N non lo hai fissato costante, ma lo hai inizializzato nel costruttore di Client creando socketClientArray come array dinamico alla fine nel distruttore farai anche:

delete[] socketClientArray;

P.S.: Cionci seguivamo insieme i corsi del Lenzini a Pisa x caso???

[cionci]

Se gli servissero più di due oggetti può avere senso, ma se gli servono solo due oggetti è over-ingegnerizzazione

[Ikon O'Cluster]

Originariamente inviato da Ikon O'Cluster

P.S.: Cionci seguivamo insieme i corsi del Lenzini a Pisa x caso???

[Ikon O'Cluster]

Cmq non è super ingegnerizzazione ma semplicemente buona programmazione!

[luxorl]

Mi servono solo due oggetti non capisco perché dichiararmi un array
Comunque ho optato (con l'approvazione del Lipari (ho notato che avete studiato a Pisa)) per inserire due bei puntatori agli oggetti interni e inizializzarli con una new quando voglio

Grazie a tutti

[Ikon O'Cluster]

Eh il Lipari!!! Ma che mito!!! Eh... tanto tra 2 puntatori e un array, non è che perdi memoria... è la stessa, anzi forse ci guadagni lievemente in efficienza

[cionci]

Originariamente inviato da Ikon O'Cluster

Cmq non è super ingegnerizzazione ma semplicemente buona programmazione!

Può essere
L'ho seguito nel 2005/6...che malloppone quell'esame

[Ikon O'Cluster]

Si che allora l'abbiamo seguito insieme!!! La rete è proprio piccola!

[cionci]

Davvero

Riguardo ad usare un vettore, questa è la mia filosofia (che applico un po' a tutto il codice che scrivo): "Premature optimization is the root of evil" (cit. Donald Knuth), questo include anche qualsiasi pezzo di codice atto a supportare una modifica futura del codice, ma non prevista dalle attuali specifiche.
Imho questa ci ricade a pieno

Sulle prestazioni: se una cosa può essere, al massimo può essere più lento perché si fa uso dell'aritmetica dei puntatori. Ad esempio in alcune architetture l'indirizzamento con displacement può non essere previsto, quindi comporta una istruzione assembly in più. Al 99% le due variabili si troveranno in zone contigue o comunque cachate. Quindi accedere al primo non genererà un cache miss e quindi un accessi alla memoria in più.

[Ikon O'Cluster]

Si infatti, consideravo proprio la cache. Cmq fare un vettore di 2 elementi o fare 2 soli puntatori separati, non cambia proprio niente. Mi dispiace con l'amico della citazione, ma se uno programma con criterio semmai succede proprio il contrario. L'ottimizzazione spinta è un'altra cosa, penso che la citazione si riferisca ad artifici perversi che alla fine fanno un macello solo x risparmiare una riga di codice. Poi sulle architetture che non supportano la cosa, penso che il compilatore punti ad ottimizzare in questo senso, no?

[cionci]

Originariamente inviato da Ikon O'Cluster

ma se uno programma con criterio semmai succede proprio il contrario.

Non sono d'accordo. Pensare in quest'ottica aumenta solamente la complessità del codice, quindi aumentano le linee di codice, aumenta il tempo di scrittura, probabilmente aumenta la difficoltà di lettura, aumentano il numero di bug e aumenta la difficoltà nell'applicare modifiche al codice.
Ad esempio mettiamo che in futuro venga adottata una soluzione che si era prevista al momento della scrittura, ma la si vuole ottenere in modo completamente diverso da quello che si era implementato: chiaramente si perde molto più tempo ad applicare queste nuove modifiche.
Poi se una cosa è prevista in ottica futura anche dalle specifiche è tutto un altro discorso (vedi protocolli, con i campi lasciati per utilizzi futuri), ma programmare pensando a quello che il software potrebbe diventare e non pensando a quello che il software attualmente deve essere, imho, è una pratica alquanto scorretta.

[Ikon O'Cluster]

OK cionci... allora non avevo capito cosa volevi dire! Ora ti sei spiegato meglio.

[tomminno]

Originariamente inviato da cionci

Davvero

Riguardo ad usare un vettore, questa è la mia filosofia (che applico un po' a tutto il codice che scrivo): "Premature optimization is the root of evil" (cit. Donald Knuth), questo include anche qualsiasi pezzo di codice atto a supportare una modifica futura del codice, ma non prevista dalle attuali specifiche.
Imho questa ci ricade a pieno

Purtroppo invece nelle condizioni lavorative il 90% dei problemi viene da soluzioni tarate ad hoc per quello che il programma deve fare nel momento in cui è scritto, poi però passa il tempo c'è da modificare qualcosina, il programma c'è già, inutile rifarlo si usa quello che c'è e si aggiunge un mattoncino a secco su una casetta in legno.
Ripetere l'operazione n-mila volte...
Se le specifiche attuali non lo prevedono ma se la storia ti insegna che sicuramente domani ci saranno solo perchè qualcuno si alza storto (oppure non ha mai letto la documentazione preliminare che pure ha approvato) e il progetto viene stravolto, che fare?

[cionci]

Originariamente inviato da tomminno

Se le specifiche attuali non lo prevedono ma se la storia ti insegna che sicuramente domani ci saranno solo perchè qualcuno si alza storto (oppure non ha mai letto la documentazione preliminare che pure ha approvato) e il progetto viene stravolto, che fare?

Dipende dal tipo di progettazione, ma in genere si rimette mano al progetto, si scrivono le modifiche e si passano tutte le fasi di approvazione.
Per un semplice motivo: la soluzione che viene in mente al singolo programmatore può non essere la migliore. Questo perché, almeno in un progetto grande, la visione che ha il programmatore del problema potrebbe essere parziale o comunque con un refactoring a più alto livello di astrazione il problema potrebbe essere spostato altrove.
Faccio un esempio legato al tema proposto, invento un po' eh. Mettiamo che questo oggetto client che contiene due end point sia un client che si connette a due coppie di host. Mettiamo che io supponga che il software si possa connettere a diverse coppie di host. Per questo organizzo un vettore di coppie di end point all'interno dell'oggetto client. La mia supposizione però mi potrebbe portare ad un design sbagliato, perché io, che mi occupo di scrivere la classe client, ho solo una visione parziale del problema.
Magari vedendo il problema da un diverso livello di astrazione mi sarebbe bastato allocare un vettore di oggetti client semplificando notevolmente il codice interno alla classe client.