Newsgroup: it.comp.lang.c++
Titolo: Mi piace la programmazione

Salve, 
	sono Stefano Cristiano e sono uno di qui tipi che solo 
saltuariamente faceva la sua comparsa sul newsgroup. Ho deciso di
prendere parte attiva alle discussioni e mi era sembrato giusto
presentarmi brevemente.
Sono un ragazzo di 15 anni (fra una settimana ne avro' 16)
che da circa 1 anno e 1/2 programma in C, Java, C++ e altri linguaggi
di contorno come javascript, vbscript, CFML ecc.
Leggo continuamente riviste, libri, documentazioni di programmazione
per tenermi sempre aggiornato.
So lavorare con le Api, VCL e anche un po' con MFC.
Benche' per lavoro (ebbene si', mi hanno gia' ingaggiato per la
realizzazione
di siti interattivi on-line), coltivo per passione lo studio della
programmazione _seria_ in C++. I miei argomenti preferiti sono:
Grafica computerizzata (directx), realizzazione di GUI e di videogiochi.
tra gli altri libri, ho letto la verisone beta di thinkin' in C++ di
Eckel.
Non sono un esperto, ma non mi ritengo neanche un novizio dato che 
studio assiduamente C++ da parecchio tempo.
 
Come prima richiesta 'ufficiale', volevo sapere dove trovare qualcosa
per iniziare a capire qualcosa di COM con annessi e connessi.
Ho scaricato dal sito 
mcp.com
 il libro ActiveX programming with Visual
C++
dove viene spiegato un po' di questa roba, ma volevo approfondire
di piu' l'argomento.
Inoltre sarei seriamente intenzionato a trovare qualcuno che
collaborasse
con me alla stesura del progetto di una libreria per gestire la grafica
directX (mappe, toolbars, menu ecc.). A dir la verita' mi servirebbero
parecchi consigli non tanto sull'implementazione tecnica, che credo
di poter portare avanti da solo, quanto sul'albero genealogico della 
struttura di classi. Non sono sicuro di come impostare il progetto,
perche' non vorri ricadere nei miei errori del passato, dove ho passato
poco tempo a progettare e mi sono ritrovato con del codice immondizia
che funzionava, ma che "incapsulamento, ereditarieta' e estensibilita'"
li vedeva con il cannocchiale. 
La cosa strana e' che, provenendo da un'esperienza di Java, sono stato
abituato sempre a pensare ad oggetti, ma non so per quale motivo, da
quando programmao in c++ mi sembra di essere scaduto un po'.
Il sistema che vorrei realizzare e' fatto di bottoni, finestre, e barre.
Il codice deve essere il piu' possibile sciolto da qualsiasi 
personalizzazione per un determinato videogioco, dato che devo poterlo
riutilizzare in piu' occasioni, magari realizzando un piccolo editor 
visuale come ho gia fatto per gli sprite.
Che ne dite parto cosi'?
Mettiamo alla base di tutto una finestra. Penso che il concetto di
finestra,
cioe' di una entita' che sia capace di ottenere una parte di schermo,
sia
molto simile alla ben conosciuta HWND di win32.
class Finestra------class FinestraFrame
	|
	|
	|
class BottoneRealtime
	|
	|
	|
class BottoneBitmap
	|
	|
	|
	|
class Bottone2Stati
ecc.
Tre i miei dubbi principali ci sono per esempio:
e' sensato creare come base un bottone real time, e cioe' un bottone
che viene disegnato on the fly tramite linee, e derivare da esso il
bottone
bitmap? Oppure e' meglio mettere il bottone bitmap come fratello di del
bottone
realtime?
E sensato derivare dal bittone bitmap un bottone 2 stati (quando
l'utente
passa sopra col mouse o no)? Oppure e' meglio impostare dei parametri
nel bottone bitmap che gli permettano di lavorare con N stati?
Tutte queste entita' devono compiere delle azioni comuni come muoversi,
ruotare, ecc.., sia da soli che in gruppo. Devo creare dei metodi
astratti
nella classe madre  che obblighino ogni entitia' ad implementare la
propria
funzione in modo appopriato?
Dovrei anche creare quindi una classe che gestisca insiemi di
'controlli',
se cosi li possiamo definire (oltre ai bottoni ci saranno gli slider, 
le caselle di testo ecc..)) i modo che muovere il 'conenitore' equivalga
a muovere tutti i controlli in esso conenuti.
Come dovrei impostare il modello di eventi (pressione del bottone,
spostamento
di uno slider ecc.)? Il pattern che mi sembra piu' adatto e' quello 
dell'observer - observable che, se non sbaglio, e' caratteristico di
Java.
Il delegation-model (si chiama cosi?) permette una soluzione in linea
con
la programmazione ad oggetti.? Non sono esperto di pattern, e vorrei
sapere
quale sia il piu' adatto.
Quello che mi servirebbe e' appunto un'idea, nelle linee generali, di
come
portare avanti questo progetto.
Su questo newsgroup ci sono certi maghi della progettazione, ed io sono
qui
appositamente per imparare da loro...
Fatevi sentire!!!
-- 
*******************************************
Pagghiu-Stefano Cristiano
Java and C++ programmer
E-mail: 
spag...@tin.it
 ITALY
*******************************************

qui appositamente per imparare da loro...
Non mi offro certo di sviluppare il progetto al posto tuo, ma
volentieri invece di offrire critiche, consigli, e osservazioni
su quanto su questo gruppo possa venire discusso.
Alex

quale sia il piu' adatto.
Non conosco il pattern observer-observable.
Direi che la classe Finestra dovrebbe avere una sorta di OnMessage() per
ricevere messaggi spediti da chiunque. In generale direi che le modifiche ad
un oggetto dovrebbero tutte passare attraverso la spedizione di un messaggio
ad esso piuttosto che chiamare direttamente un metodo della classe che
lavori direttamente sull'oggetto perche' ci sarebbero problemi di
serializzazione e di sincronismo.  Windows funziona cosi'.
Ciao.
Antonio Donatiello

 Alex
Nessuno ha chiesto di sviluppare il lavoro al posto mio. Se volessi
fare cosi', non avrei fatto tante domande sull'argomento. ;-.)   
(credo che sia una faccina con un neo).
Comunque grazie perche' mi hai chiarito davvero molto dubbi e,
senza scherzare, mi hai fatto una "lezione ad oggetti".
Finalmente sono uscito allo scoperto, dichiarando la mia eta',
cosa che solitamente preferisco non fare perche' molte volte 
non mi prendono in considerazione.
Ribadisco che non mi ritengo un novizio, ne' un esperto, ma uno
STUDIOSO si C++ con tanta, tanta passione. Credo che questo sia
gia' un traguardo...
Ciao facce da C++


 Alex
Nessuno ha chiesto di sviluppare il lavoro al posto mio. Se volessi
fare cosi', non avrei fatto tante domande sull'argomento. ;-.)   
(credo che sia una faccina con un neo).
Comunque grazie perche' mi hai chiarito davvero molto dubbi e,
senza scherzare, mi hai fatto una "lezione ad oggetti".
Finalmente sono uscito allo scoperto, dichiarando la mia eta',
cosa che solitamente preferisco non fare perche' molte volte 
non mi prendono in considerazione.
Ribadisco che non mi ritengo un novizio, ne' un esperto, ma uno
STUDIOSO si C++ con tanta, tanta passione. Credo che questo sia
gia' un traguardo...
Ciao facce da C++


 Antonio Donatiello
Ciao e grazie.


gia' un traguardo...
Altro che!  La passione, e lo studio, sono le cose fondamentali...
Alex

solo...)
Era chiaro. Quello che volevo enfatizzare era solo il fatto che la
spedizione dei messaggi tra gli oggetti ti permette di "serializzare" gli
eventi, cosa molto comoda nel caso di programmi multi threading.
Ciao.
Antonio Donatiello.

non mi viene in mente un quali.
La chiave e` un'osservazione di Bertran Meyer: "Real systems have
no top"!  Un classico progetto top-down tende a produrre codice con
zero riusabilita`, in quanto ogni riga scritta e` tesa all'unico specifico
scopo del progetto in corso; ma nella realta`, se oggi scrivo una data
applicazione nel dominio X, probabilmente domani l'altro dovro` poi
scriverne un'altra, e fara` una differenza _enorme_ se io potro`, o meno,
riusare una buona parte del codice, e del progetto, che sto scrivendo
oggi.  Una "giusta" dose di bottom-up mi avra` permesso di sviluppare
classi "fondazionali", con un insieme di funzionalita` ben calibrato fra
i due poli [a] le specifiche esigenze del primo progetto e [b] l'eleganza
intrinseca delle fondamenta stesse (completezza, minimalita`, e
generalita`); e` improbabile che io sia stato cosi` bravo da riuscire a
riusarle "alla perfezione" ("a scatola chiusa", "secondo il principio
open-closed", ecc) gia` al secondo progetto, ma, incrementalmente
e gradualmente, questo e` lo scopo che ci si prefigge.  Stando attenti
anche a non farsi travolgere dall'entusiasmo per la generalita` in
misura eccessiva, ovvio; per essere RI-usabile, il codice, ovvero un
progetto, deve anzitutto essere _usabile_ (non troppo ricco, non
troppo complesso, ben testabile e ben testato, ecc).
Bottom-up e` dunque sicuramente appropriato (in misura preponderante
su top-down) tutte le volte che progetto componenti "fondazionali" -- quanto
piu` generali, tanto piu` appropriato (meglio ancora e` riusare buon codice
altrui, per scopi sufficientemente generali, quando possibile: ad esempio,
usare tutte le ottime librerie standard C++, invece che progettarsi da soli
stringhe, contenitori, I/O formattato, eccetera!-).  Top-down serve in primo
luogo per partizionare un compito in _componenti_; bottom-up, per definire
quali di questi componenti potranno essere resi riusabili, in quale misura,
con quali caratteristiche d'interfaccia, eccetera.
Alex