C++ ed HTML - Pagina 2

misterx · 13-01-2003, 16:08

Quote:

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

Questo e' un esempio che mostra perche' un linguaggio che supporti solo la programmazione OO (come Java) nonj e' il massimo. Ci sono cose che risultano migliori fatte in modo procedurale, altre se fatte ad oggetti. Non ha senso costruire un oggetto per fare il lavoro di una funzione (a meno che non ti serva un oggetto-funzione ovviamente

).

pensa che nonostante io programmi in un ambiente completamente ad oggetti, non ne ho mai avuto la necessità di implementarne dei miei: mah...

forse scrivo programmi troppo banali

cionci · 13-01-2003, 19:16

Quote:

Originally posted by "misterx"

forse scrivo programmi troppo banali

Questo è il problema dei linguaggi con framework completi come il BC++B, Delphi e Java... Si finisce con il far diventare la programmazione ad oggetti un accessorio...ed in pratica si ritorna a programmare in maniera imperativa...
Sinceramente con MFC mi sono trovato a definire molto spesso oggetti derivati da oggetti del framework (è una cosa molto comune, si chiama subclassing) per aggiungerne funzionalità e gestirne i messaggi...

Non perchè scrivi programmi banali (non è detto che un programma non banale necessiti per forza di oggetti), ma perchè probabilmente ciò che scrivi si appoggia principalmente all'interfaccia per cui gli oggetti sono già definiti...

misterx · 13-01-2003, 19:24

e allora significa che spremo bene ciò che ho a disposizione; almeno credo, certo, finchè dura cioè: fino a che mi va di lusso

poi magari se ne riparlerà.....

devo ammettere che non è facile slegarsi dalla programmazione procedurale o "top down" del vecchio C; sono nato su questo linguaggio

penso sia solo una questione di mentalità

cmq, sto provando ad aggiungere, per curiosità, il metodo "Resize" ad un componente di tipo TImage: ne è sprovvisto

se la storia non diviene troppo lunga inizierò anch'io questa avventura

cionci · 13-01-2003, 19:35

Dovrebbe bastare derivare pubblicamente la tua classe da TImage ed aggiungere resize come metodo pubblico...

misterx · 13-01-2003, 19:44

e sicuramente potrei chiamare il nuovo metodo Resize() con:

Image1->Resize(320,240);

oppure volendo eliminare una componente nel colore RGB di una immagine potrei scrivere:

Image1->RGB_TieniSolo(B);

etc...etc...

cionci · 13-01-2003, 19:48

Sì !!!

misterx · 13-01-2003, 19:56

Quote:

Originally posted by "cionci"

Sì !!!

però, personalizzare altamente un ambiente ha i suoi pro e contro; il primo contro che mi viene in mente è che ti devi produrre documentazione per ricordarti l'uso delle personalizzazioni

sai, lo faccio già tutto il santo giorno ed alla sera divento pigro

sono convinto che se usassi per un pò BCB (magari lo hai già fatto) ti accorgeresti che non è poi tanto male

BCB mi piace in quanto digerisce di tutto, lo trovo un ambiente molto aperto alle personalizzazioni

però ti faccio una domanda per la quale non ho ancora ben colto:
non ho capito che distinzione faccia BCB tra un componente ed una classe, di primo acchito a me paiono la stessa cosa se non chè, un componente possiede una parte grafica, una classe penso di no, nonostante entrambi posseggano metodi proprietà ed eventi: di questi ultimi non ne sono sicuro per quanto riguarda le classi

cionci · 13-01-2003, 20:00

Lo scopo principale degli oggetti non è solo la personalizzazione, ma la possibilità di riutilizzare facilmente il codice dell'oggetto...

Non mi sembra di aver detto che non è un buon ambiente, anzi lo apprezzo molto

Sicuramente un componente è una classe, ma è anche un "tasto" da mettere nella toolbar...per poterlo inserire in maniera visuale nell'applicazione... Sinceramente non conoscendo bene l'ambiente non so come si realizzano...

misterx · 13-01-2003, 20:07

per la creazione di componenti BCB ti crea un ambiente guidato del tipo:

Nuovo->Componente

hanno lavorato veramente molto bene i signori della Borland, magari avessi scritto io un tale ambiente

eh, ci vogliono altre conoscenze

/\/\@®¢Ø · 13-01-2003, 21:33

Quote:

Originally posted by "misterx"

pensa che nonostante io programmi in un ambiente completamente ad oggetti, non ne ho mai avuto la necessità di implementarne dei miei: mah...

forse scrivo programmi troppo banali

Piu' che altro dipende dal tipo di programmi che fai. Raramente un "comune programmatore" ha bisogno di crearsi tutta una gerarchia di oggetti, pero' se confronti la difficolta' nell'utilizzare una interfaccia grafica C tipo gtk e una in C++...

.
Come diceva cionci comunque gli oggetti vanno bene non solo per la personalizzazione. Sono comodi per definire comportamenti generali (ad esempio quando fai una funzione che usa uno stream, va bene con qualsiasi stream, che sia la console, un file, un socket ), e senza necessariamente dover definirne di nuovi
In C++ inoltre sono usati spesso come funzioni in cui si ha bisogno di una "memoria locale" alla funzione stessa

misterx · 14-01-2003, 06:37

Quote:

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

Piu' che altro dipende dal tipo di programmi che fai. Raramente un "comune programmatore" ha bisogno di crearsi tutta una gerarchia di oggetti, pero' se confronti la difficolta' nell'utilizzare una interfaccia grafica C tipo gtk e una in C++...

.
Come diceva cionci comunque gli oggetti vanno bene non solo per la personalizzazione. Sono comodi per definire comportamenti generali (ad esempio quando fai una funzione che usa uno stream, va bene con qualsiasi stream, che sia la console, un file, un socket ), e senza necessariamente dover definirne di nuovi
In C++ inoltre sono usati spesso come funzioni in cui si ha bisogno di una "memoria locale" alla funzione stessa

però mi sto accorgendo che aggiungendo nuovi comportamenti ad oggetti già predefiniti da altri, sta diventando anche una mia necessità

cionci · 14-01-2003, 08:59

Se ti interessa vedere le potenzialità degli oggetti....ecco qua un bel link che parla dei design patterns... I design patterns sono linee guida per la creazione di classi e gerarchie di classi che devono espletare alcune particolari funzioni... I diagrammi che vedi nel link sono fatti in UML...

http://home.earthlink.net/~huston2/dp/patterns.html

Ti posso fare un semplice esempio in cui usare una gerarchia di classi è fondamentale...
Pensa di dover fare un software di disegno tipo Corel Draw...
I vari oggetti che puoi emttere sulo schermo saranno generalizzati da una classe drawObject... Tutti i vari oggetti deriveranno direttamente o indirettamente da drawObject...
Ad esempio Ellipse, Text, Rectangle deriveranno direttamente da drawObject...
Circle deriverà da Ellipse... RoundedRectangle (rettangolo con gli spigoli arrotondati) e Box (quadrato) deriveranno da Rectangle...ad esempio da ogni componente puoi far derivare una altro componente che ha l'interno riempito...

In questo modo quando dovrà essere applicata una funzione su un qualsiasi oggetto basterà applicarla su drawObject...

Ad esempio :

Codice:

void Commands::Remove(drawObject *d, drawPage *p)
{
   objData data = p-&gt;FindObject(d);
   p-&gt;RemoveObject(data);
}

Questa stessa funzione andrà bene per TUTTI gli oggetti della gerarchia !!!
Inoltre grazie all'"information hiding" (cioè il tenere private all'interno delle classi le variabili membro) si ha anche una certa indipendenza sull'implementazione di drawPage (posto che anche drawPage potrebbe essere una gerarchia di classi)...
Ad esempio da questa funzione non si vede come vengono memorizzati gli oggetti...potrebbe essere una lista, uno stack (utile in questi casi, perchè per un buon 50% dei casi si andrà a lavorare sull'ultimo oggetto creato) o un vettore dinamico...

misterx · 14-01-2003, 19:18

moooolto interessante, altrochè se mi interessa, se può semplificarti la vita

quando hai parlato di "subclassing" o termine similare è la medesima cosa di "discendenza"?

oppure "discendenza" è un termine usato per indicare che una proprietà o metodo che appertengono si ad un oggetto ben definito ma che per similitudine può essere usato anche per altri tipi di oggetto?

pardon se la domanda è un pò strana

cionci · 14-01-2003, 19:37

Il subclassing è la derivazione di un oggetto del framework per aggiungerci funzionalità...
Discendenza non l'ho mai sentito dire...
La classe derivata dall'oggetto del framework ne eridita dati e metodi (a seconda del tipo di derivazione)...

misterx · 14-01-2003, 19:41

Quote:

Originally posted by "cionci"

Il subclassing è la derivazione di un oggetto del framework per aggiungerci funzionalità...
Discendenza non l'ho mai sentito dire...
La classe derivata dall'oggetto del framework ne eridita dati e metodi (a seconda del tipo di derivazione)...

più propriamente "descendant"; la documetazione di BCB è strapiena di questo termine e inizio a pensare che sia la medesima cosa di "derivata" come sostieni tu

cmq, mi sto muovendo: con calma ma mi sto muovendo

14-01-2003, 08:59	#32
cionci Senior Member Iscritto dal: Apr 2000 Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29 Messaggi: 53971	Se ti interessa vedere le potenzialità degli oggetti....ecco qua un bel link che parla dei design patterns... I design patterns sono linee guida per la creazione di classi e gerarchie di classi che devono espletare alcune particolari funzioni... I diagrammi che vedi nel link sono fatti in UML... http://home.earthlink.net/~huston2/dp/patterns.html Ti posso fare un semplice esempio in cui usare una gerarchia di classi è fondamentale... Pensa di dover fare un software di disegno tipo Corel Draw... I vari oggetti che puoi emttere sulo schermo saranno generalizzati da una classe drawObject... Tutti i vari oggetti deriveranno direttamente o indirettamente da drawObject... Ad esempio Ellipse, Text, Rectangle deriveranno direttamente da drawObject... Circle deriverà da Ellipse... RoundedRectangle (rettangolo con gli spigoli arrotondati) e Box (quadrato) deriveranno da Rectangle...ad esempio da ogni componente puoi far derivare una altro componente che ha l'interno riempito... In questo modo quando dovrà essere applicata una funzione su un qualsiasi oggetto basterà applicarla su drawObject... Ad esempio : Codice: void Commands::Remove(drawObject d, drawPage p) { objData data = p->FindObject(d); p->RemoveObject(data); } Questa stessa funzione andrà bene per TUTTI gli oggetti della gerarchia !!! Inoltre grazie all'"information hiding" (cioè il tenere private all'interno delle classi le variabili membro) si ha anche una certa indipendenza sull'implementazione di drawPage (posto che anche drawPage potrebbe essere una gerarchia di classi)... Ad esempio da questa funzione non si vede come vengono memorizzati gli oggetti...potrebbe essere una lista, uno stack (utile in questi casi, perchè per un buon 50% dei casi si andrà a lavorare sull'ultimo oggetto creato) o un vettore dinamico...

13-01-2003, 19:24	#23
misterx Senior Member Iscritto dal: Apr 2001 Città: Milano Messaggi: 3736	e allora significa che spremo bene ciò che ho a disposizione; almeno credo, certo, finchè dura cioè: fino a che mi va di lusso poi magari se ne riparlerà..... devo ammettere che non è facile slegarsi dalla programmazione procedurale o "top down" del vecchio C; sono nato su questo linguaggio penso sia solo una questione di mentalità cmq, sto provando ad aggiungere, per curiosità, il metodo "Resize" ad un componente di tipo TImage: ne è sprovvisto se la storia non diviene troppo lunga inizierò anch'io questa avventura

13-01-2003, 19:35	#24
cionci Senior Member Iscritto dal: Apr 2000 Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29 Messaggi: 53971	Dovrebbe bastare derivare pubblicamente la tua classe da TImage ed aggiungere resize come metodo pubblico...

13-01-2003, 19:44	#25
misterx Senior Member Iscritto dal: Apr 2001 Città: Milano Messaggi: 3736	e sicuramente potrei chiamare il nuovo metodo Resize() con: Image1->Resize(320,240); oppure volendo eliminare una componente nel colore RGB di una immagine potrei scrivere: Image1->RGB_TieniSolo(B); etc...etc...

13-01-2003, 19:48	#26
cionci Senior Member Iscritto dal: Apr 2000 Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29 Messaggi: 53971	Sì !!!

13-01-2003, 20:00	#28
cionci Senior Member Iscritto dal: Apr 2000 Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29 Messaggi: 53971	Lo scopo principale degli oggetti non è solo la personalizzazione, ma la possibilità di riutilizzare facilmente il codice dell'oggetto... Non mi sembra di aver detto che non è un buon ambiente, anzi lo apprezzo molto Sicuramente un componente è una classe, ma è anche un "tasto" da mettere nella toolbar...per poterlo inserire in maniera visuale nell'applicazione... Sinceramente non conoscendo bene l'ambiente non so come si realizzano...

13-01-2003, 20:07	#29
misterx Senior Member Iscritto dal: Apr 2001 Città: Milano Messaggi: 3736	per la creazione di componenti BCB ti crea un ambiente guidato del tipo: Nuovo->Componente hanno lavorato veramente molto bene i signori della Borland, magari avessi scritto io un tale ambiente eh, ci vogliono altre conoscenze

14-01-2003, 19:18	#33
misterx Senior Member Iscritto dal: Apr 2001 Città: Milano Messaggi: 3736	moooolto interessante, altrochè se mi interessa, se può semplificarti la vita quando hai parlato di "subclassing" o termine similare è la medesima cosa di "discendenza"? oppure "discendenza" è un termine usato per indicare che una proprietà o metodo che appertengono si ad un oggetto ben definito ma che per similitudine può essere usato anche per altri tipi di oggetto? pardon se la domanda è un pò strana

14-01-2003, 19:37	#34
cionci Senior Member Iscritto dal: Apr 2000 Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29 Messaggi: 53971	Il subclassing è la derivazione di un oggetto del framework per aggiungerci funzionalità... Discendenza non l'ho mai sentito dire... La classe derivata dall'oggetto del framework ne eridita dati e metodi (a seconda del tipo di derivazione)...

Strumenti
Mostra una versione stampabile Invia questa pagina per email