|
|||||||
|
|
|
![]() |
|
|
Strumenti |
|
|
#1 |
|
Member
Iscritto dal: Dec 2006
Messaggi: 198
|
[C++] Funzioni nel polimorfismo
Salve a tutti
Il mio problema ho questo: immaginate di avere una classe "oggetto" oggetto figlia e nascono "armatura" e "arma", che sono classi ereditate armatura conterrà il metodo: setDefense spada: setDamage Fin qui tutto chiaro. Ora dichiaro un array di puntatori ad "oggetto", e a seconda della necessità ci alloco "armatura" o "arma". Voglio fare ora una routine che li carica. Il problema è che, a seconda del fatto che sia "arma" o "armatura", devo usare setDamage o setDefense. Ma, essendo un array di "oggetti", non vede nessuno dei due metodi. Ok, forse l'ho tirata un po' per le lunghe, ma, in sostanza, esiste un modo bello e pulito di risolvere la cosa? Senza dover ricorrere a funzioni fasulle, chiamare funzioni esterne, ecc. |
|
|
|
|
|
#2 |
|
Senior Member
Iscritto dal: May 2004
Città: Napoli
Messaggi: 773
|
Beh "purtroppo" l'unica soluzione che mi sembra attuabile è quella di avere in oggetto un metodo virtuale puro set() implementato in armatura per richiamare setDefense() e in arma per richiamare setDamage().
Dico purtroppo perchè credo sia questo che tu intendi per "funzioni fasulle" ma in particolare se oggetto non contiene i due metodi (e mi sembra una scelta concettualmente corretta) non c'è altro modo per richiamarle.
__________________
If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. --Gerald Weinberg |
|
|
|
|
|
#3 |
|
Senior Member
Iscritto dal: Feb 2006
Messaggi: 1304
|
potresti mettere
"bool isWeapon()" e "bool isArmor()" virtuali in Object, e poi reimplementarli in Armatura e Arma con i dovuti true e false, per poter sapere dall'esterno che tipo di oggetto stai gestendo. Però IMHO in questa maniera il polimorfismo salta, meglio usare il metodo set() generico come ha detto Albi89 |
|
|
|
|
|
#4 |
|
Member
Iscritto dal: Dec 2006
Messaggi: 198
|
Il problema non è tanto sapere di che tipo è, per quello ho già un char... Il fatto è che se faccio
oggetto* O if ( è un armatura ) O = new armatura O->setDefence(...) <--errore di compilazione else if ( è un arma ) O = new arma O->setDamage(...) L'idea del set ha il problema che purtroppo non c'è solo la difesa da settare, ma ci saranno altre set... A quel punto potrei fare un'unica set virtuale che prende una ccostante per gestire il parametro, e da altre parti lo faccio, ma per dei motivi lo vorrei evitare qui... Un'idea potrebbe essere questa: al posto di O->setDefence() mettere setDefence( ( cArmor* )O ) e poi faccio una funzioncina a parte che, avendo come parametro una cArmor, non dovrebbe lamentarsi... Che ne dite, funzierebbe? |
|
|
|
|
|
#5 |
|
Senior Member
Iscritto dal: Feb 2006
Messaggi: 1304
|
Codice:
//allora i metodi is possono fungere anche da type cast:
//esempio per Armor
virtual Object* Object::isArmor() { return NULL; }
Armor* Armor::isArmor() { return this; }
...
if(object->isArmor())
armatura = object->isArmor();
//e cosi' puoi chiamare direttamente setDefense o quello che e'
...
|
|
|
|
|
|
#6 |
|
Member
Iscritto dal: Dec 2006
Messaggi: 198
|
Dio mio O.o"
Proverò, grazie mille |
|
|
|
|
|
#7 |
|
Senior Member
Iscritto dal: Feb 2006
Messaggi: 1304
|
Hai voluto il polimorfismo? E mo pedali
Cmq quel metodo non è malaccio IMHO, è rapido, evita casts e lo usa anche PhysX. L'unico problema è che affolla un pò Object con metodi di controllo... |
|
|
|
|
|
#8 |
|
Member
Iscritto dal: Dec 2006
Messaggi: 198
|
Effettivamente è il metodo più pulito che ho visto fin'ora, però che diamine -.- Ah, w gli algoritmi, la programmazione tecnica non mi piace -.-
|
|
|
|
|
|
#9 |
|
Senior Member
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
|
Mi loggo giusto perché ho visto questa cosa e dato che l'argomento mi stuzzica...
Usare isArmor o isWeapon va contro il polimorfismo. Se fai un uso di quel tipo tanto vale farti una collection di Armor ed una collection di Weapon. Ci sono altri modi, che però non sono validi per predeterminare il tipo dell'oggetto e solo successivamente dare un valore ai dati "caricamento". Uno, soprattutto valido nel caso tu abbia oggetti che fanno sia difesa che attacco (o che abbiano altre "proprietà" contemporaneamente), è il null object. All'oggetto base Object aggiungi due metodi: getArmorProperty e getWeaponProperty che ritornano rispettivamente un oggetto ArmorProperty ed un oggetto WeaponProperty. Se un'arma non ha proprietà di difesa getArmorProperty ritornerà un oggetto NullArmorProperty. Supponendo che ArmorProperty abbia un metodo ArmorProperty::defend la gestione dei valori sarà fatta in questo modo: Codice:
//Al caricamento
Object * object = new Object();
//questa cosa dovrebbe essere fatta nel costruttore di Object
object->setArmorProperty(new NullArmorProperty());
object->setArmorProperty(new NullWeaponProperty());
if(devo caricare un'arma) //lo predetermi dal tipo di dati che carichi
{
//qui in teoria potresti anche variare il tipo di armatura caricata (in questo caso Basic)
myObject->setArmorProperty(new BasicArmorProperty());
myObject->getArmorProperty()->setDefense(myDefense);
}
if(devo caricare un'armatura)
{
//qui in teoria potresti anche variare il tipo di arma caricata
myObject->setWeaponProperty(new BasicWeaponProperty());
myObject->getWeaponProperty()->setDamage(myDamage);
}
myCollection.push_back(myObject);
Codice:
class NullArmorProperty: public BasicArmorProperty
{
NullArmorProperty(){};
virtual void setDefense(int defense){};
virtual void absorbDamage(int &sufferedDanage) {};
};
Con ogni oggetto potrai tranquillamente difendere o attaccare: in caso di difesa non influirà sul risultato finale ed in caso di attacco non provocherà alcuna azione (anche se in caso di attacco, non so che tipo di gioco tu stia facendo, ma probabilmente deciderai prima con quale oggetto attaccare). |
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 01:05.



















