Problema tecnico(di OOP): risalire da un'istanza di oggetto all'istanza di oggetto che lo contiene

[Fire-Dragon-DoL]

Mi spiego meglio con un esempio:

class Statistiche	attr_accessor :str	attr_accessor :dex	attr_accessor :int	def initialize		@str=0		@dex=0		@int=0		@atbmax=100		@atb=0	end	def atb=(value)		@atb=value		if (@atb>=@atbmax)			@atb=@atbmax			iniziaturno(il_pg) #qua è dove sorge il problema: vorrei risalire a chi contiene l'istanza di "stats"		end	end	def atb		if (@atb>@atbmax)			return @atbmax		else			return @atb		end	end	def iniziaturno(chara)		#eventuali cose da fare se inizia il turno	endendclass Combattente	attr_accessor :stats	def initialize		@stats=Statistiche.new	endend Eroe=Combattente.newEroe.stats.str=12Eroe.stats.int=34Eroe.stats.dex=3Eroe.stats.atb=100 #L'atb è carico#come potete vedere non ho un modo per risalire al mio pg da dentro "atb="

 

La prima soluzione che mi è venuta in mente è qualcosa tipo un campo "handler" dentro a Statistiche per cui

class Combattente	attr_accessor :stats	def initialize		@stats=Statistiche.new(self)	endendclass Statistiche	attr_accessor :handler	def initialize(il_pg)		@handler=il_pg	endend

 

quindi cambiando le classi in questo modo dovrei poter accedere tramite Eroe.stats.handler a "Eroe" e da li quindi vedrei il tutto anche dentro ad "atb=", ora questo è sensato...ma mi sembra una vera e propria porcata. E' un errore di progettazione?Come approccio, dovrei tirar tutto fuori dalle stats immagino?

 

si accettano suggerimenti (mi sto impegnando molto nell'imparare a progettare un programma (gioco) con l'OOP perchè vorrei poi sfruttare ciò che ho appreso anche in altri campi come università/lavoro)

Edited April 6, 2009 by Fire-Dragon-DoL

[charlie]

Questa pratica di usare degli handler è diffusa, anche se trovo anche io che non sia perfettamente in stile OOP.

Il punto qui secondo me è che il sistema di controllo dell'atb non dovrebbe essere parte del Combattente, bensì di una struttura esterna che lo controlla, che contiene i diversi oggetti Combattente, accede al campo atb, ma poi fa lei tutti i controlli.

[Fire-Dragon-DoL]

Questa pratica di usare degli handler è diffusa, anche se trovo anche io che non sia perfettamente in stile OOP.

Il punto qui secondo me è che il sistema di controllo dell'atb non dovrebbe essere parte del Combattente, bensì di una struttura esterna che lo controlla, che contiene i diversi oggetti Combattente, accede al campo atb, ma poi fa lei tutti i controlli.

 

Ti ringrazio (vedo che qualcuno che di oop ne capisce ci sta :P ), si noto che pure per te questa è un pò brutta come soluzione (non sapevo neanche fosse molto praticata!)...ovviamente sto facendo prima tutto su carta e penna (io l'atb lo vedevo un pò come una statistica come potrebbe invece essere la limit del personaggio) quindi l'esempio dell'atb è uno...ma per esempio, con la limit (che a tutti gli effetti è una classe simile a quella dell'atb, di conseguenza è derivata e ti posto qui sotto il perchè :P ) mi si pone lo stesso problema... poi ho fatto un oggetto "action" che contiene le seguenti informazioni "action_next" "target_next" "action_last" "target_last"...e ci volevo mettere il metodo overridabile "select_action" overridabile in modo che se casco nella classe "Mostro" (derivata di combattente) ci metto l'AI, se invece finisco nella classe "Pg" ci metto il metodo che chiama la visualizzazione del menu etc etc...anche qui, se voglio riferirmi al pg non cambia assolutamente niente

 

Il problema è che se ci rifletti non è illogico quello che sto facendo...immagina:

Francesco(io).simuove("Avanti")

Francesco.mano.stringelaspada

 

Anche se forse avrebbe piu senso Francesco.stringelapenna (ma a questo punto avremmo problemi perchè francesco avrebbe cosi tanti metodi e proprietà da arrivare di fronte al problema che avevo io precedentemente)

 

purtroppo nella realtà riesco a risalire dalla mia mano a me, in OOP no...possibile che non ci sia un modo?

 

approposito, self equivale a this (in altri linguaggi) o ho capito male?

 

EDIT:

Dimenticavo, qui l'esempio di classe atb,limit e della classe da cui ereditano

class BarStat#che nome del cavolo... non mi è venuta un'idea migliore xD	attr_accessor :speed	MAX=100	attr_reader :current	attr_accessor :graphic	def initialize(bvalue=0)		@speed=1		@current=bvalue		@graphic=GraphicBar.new#questa è inventata per ora,		#come ho detto, è mia intenzione separare la grafica dal resto e questo mi sembra l'approccio migliore		#come scritto nell'altro topic	end	def increase(howmuch=0)		if (howmuch==0)			@current+=@speed		else			@current+=howmuch		end	endendclass BarATB < BarStat	attr_accessor :reversespeed	def initialize(bvalue=0)		super(bvalue)		@reverse=false	end	def reverse=(val)		#qualcosa per invertire il caricamento dell'atb, è solo grafico l'effetto	end	def reverse		return @reverse	endendclass BarLimit < BarStat	def set(val)		@current=val	endend

 

Come vedi ha un senso...

 

Tra l'altro mentre scrivevo mi è venuto anche in mente che tra le stat del pg ci sarà "position" (che non è la posizione grafica, bensi la posizione fisica in battaglia... ovvero riga (i pg saranno disposti su 3 righe), la colonna (se è piu vicino allo schermo o meno) e poi il lato (ovvero se i pg sono a destra o a sinistra...quanto pesa fare un "reflect horizontal" di un immagine?perchè cosi non devo fare animazioni doppie :P)

 

ovviamente position è un oggetto, verrà naturale fare position.row o position.column=3 e cosi via...

come vedi, anche qui poi mi risulterebbe difficile riferirmi all'eroe

Edited April 7, 2009 by Fire-Dragon-DoL

[Fire-Dragon-DoL]

Approposito ho capito cosa intendi per "atb controlla tutto"...

 

il problema è che la cosa può essere vista in entrambi i modi...e comunque poi sorgono i problemi sopra citati per le altre classi :P

[charlie]

Il problema è che se ci rifletti non è illogico quello che sto facendo...immagina:

Francesco(io).simuove("Avanti")

Francesco.mano.stringelaspada

 

Anche se forse avrebbe piu senso Francesco.stringelapenna (ma a questo punto avremmo problemi perchè francesco avrebbe cosi tanti metodi e proprietà da arrivare di fronte al problema che avevo io precedentemente)

 

Non credo di avere capito questo pezzo...

 

Sì, self è come this.

 

Sulla riflessione delle immagini non ci ho mai lavorato molto, non saprei se e quanto è rapida.

[Fire-Dragon-DoL]

Non credo di avere capito questo pezzo...

 

Sì, self è come this.

 

Sulla riflessione delle immagini non ci ho mai lavorato molto, non saprei se e quanto è rapida.

Niente la prima cosa non mi ha saputo "rispondere" nessuno (neanche mio zio che lavora come programmatore a progetti grossi) ...non perchè fosse difficile, perchè dipende da come nel mio cervello organizzo la cosa...di conseguenza se avete qualche suggerimento su come prepararmi a organizzare (attualmente io scrivo tutto su foglio, ma sono al decimo foglio che riscrivo perchè esce sempre un gran casino...)...specialmente, devo cominciare a creare dalla classe piu "esterna" o dalla piu "interna"?(parto dalla classe Personaggio o dalla classe Statistica per dire?)...poi, conoscete qualche buon programma per disegnare diagrammi (magari gratis) e può servire a qualcosa per progettare il tutto? (se conoscete programmi che usate, comodi per progettare ditemi pure...scrivere sul blocco note è semplice ma non è molto pulito e ordinato...scrivere su word non è contempabile, mi cambia le maiuscole a suo piacimento e la mia spaziatura gli sta sul cocomero)

 

per la riflessione immagine ho scoperto che la classe Sprite ha la proprietà mirror=boolean (true/false)... non solo, non mi pare faccia mutamenti dell'immagine (a livello pratico si, ma boh)... mi pare sia molto leggera... tra l'altro comodissima...adesso posso far combattere i pg sia da destra che da sinistra disegnandoli una sola volta...finalmente posso fare gli incontri "presi alla sprovvista!" xD