Dubbi su cascata di superclassi

di il
5 risposte

Dubbi su cascata di superclassi

Salve a tutti sono nuovo del forum, sono uno studente attualmente in formazione su java. 

Come esercizio personale sto cercando di creare un mini games dove due giocatori si combattono in modo automatico finche uno dei 2 non arriva a 0 pf(una cavolata giusto per apprendere un pò).

Sto avendo problemi nel comprendere dove posizionare i method di attacco e difesa.

Attualmente c'e una classe player che gestisce l'inizializzazione del personaggio, il suo costruttore crea 2 arraylist per armi ed oggetti vuoti, imposta le statistiche prendendole dai parametri passati. Inoltre ha un get di tutte le sue proprietà ed i set per armi ed equip.

Questa classe funge da superclasse per le classi del personaggio specifico (mago, guerriero etcetc).

Fin qui non ho avuto dubbi, ora il dubbi osta al seguente passo:

devo creare 2 metodi : uno che attacca, infligge danno, ed uno che difende, subisce il danno. Inizialmente avevo pensato di fare una classe esterna che facesse questa cosa dove accettasse parametri player in ingresso.

poi ho escluso quest'opzione perchè TUTTI i player sanno attaccare e difendersi quindi la devo implementare direttamente dentro player.

pero il dubbio: direttamente in player oppure creo una sua superclasse (tipo combat system) e li metto li?


 direi la 2°  tuttavia queste classi necessitano di attributi che vengono creati nella classe player quindi o glieli passi come parametri ma mi pare brutto oppure  questi method li metto direttamente  dentro la classe player.

ovviamente mi serve a puro scopo di comprendere meglio dove collocare i method nelle varie classi.

Grazie a tutti per l'eventuale risposta :D 

5 Risposte

  • Re: Dubbi su cascata di superclassi

    Io li definirei dentro la classe Player (non ha nessun senso creare una “superclasse” di Player per questo scopo).

    Avrebbe poco senso anche una interface (credo non ci siano altri componenti se non i Player in grado di attaccare e difendere; se così non fosse, invece, la creazione di una interface avrebbe già più senso e, anche in questo caso, la farei implementare a Player).

    Farei una valutazione di tipo diverso: se ciascuna tipologia di Player deve poter attaccare/difendere in modo specifico (diverso l'una dall'altra) allora avrebbe senso crearli abstract (e, di conseguenza, diventerebbe abstract anche Player) delegando alla specifica tipologia di Player l'onere di definirli.

    Se, al contrario, tutti i player (o, diciamo, la maggior parte) devono attaccare/difendere allo stesso modo si potrebbe valutare di lasciare a discrezione delle sottoclassi la possibilità di ridefinirne il comportamento.

    Ancora, se il comportamento non deve essere ridefinito da nessuna sottoclasse, potresti valutare di definirli final.

  • Re: Dubbi su cascata di superclassi

    @SpritoLibero, “ni”

    @Paldemar, senza “saper ne leggere ne scrivere” :-) potresti fare le seguenti considerazioni

    1. hai players di DIVERSI TIPI, ogn'uno con le sue caratteristiche
      1. capacita' di attacare e tipologie di attacco
      2. capacita' di difendersi dalle diverse tipologie di attacco

    .

    Ora, come potrebbe essere implementato il fatto che P1 attacca P2 e P2 si difende da P1?

    P1.attack(attack_type, P2)    // P1 attacca P2 con lo specifico tipo di attacco
    P2.defense(attach_type)       // P2 riceve un attacco di tipo 'attach_type' e si deve difender. Non gli interessa sapere da CHI

    Quali potrebbero essere l'implementazione?
    Uso la sintassi Python giusto per non darti codice “gia' pronto” :-)
    (e banalmente perche' serve SOLO per avere una linea di pensiero :-) )

    class Player:
        def attack(attack_type, player):
            player.defense(attach_type)
            
        def defense(attach_type):
            -- player specific ---

    Ora, 
    QUALUNQUE player puo' fare un attacco. 
    MA i tipi di attacco DIPENDONO dal tipo di attacante. 

    ‘attach_type’ puo' essere qualunque cosa, da un semplice valore boolean, un intero o una struttura dati contenente informazioni aggiuntive (il numero di bombe a mano che ti sono state lanciate o il calibro del fucile a pompa)

    QUALUNQUE player deve saper difendersi, MA la capacita di difesa DIPENDE dal tipo di player.

    Quindi hai due metodi ‘attack’ e ‘defense’ a livello di classe base CON SPECIALIZZAZIONE nelle classi derivate

    Un “combat system” e' un oggetto che ha visibilita' di TUTTI i player e che, in teoria, DECIDE chi attacca chi e con quale metodo.


    Ovviamente, poi devi adattare queste idee al TUO sistema (che io non conosco)

  • Re: Dubbi su cascata di superclassi

    Buona sera e grazie mille per le risposte!

    Approvo pienamente la tua idea di non darmi codice già pronto (neanche pezzi) cosi che non possa essere influenzato o peggio ancora copiare XD  quindi grazie mille!

    Mi piace sia l'idea di definirle final (mi devo ancora abituare a questa cosa, vengo dai primi moduli fatti da front end e molte cose di java con javascript non si possono fare, almeno che io sappia :P ).

    l'idea di creare un metodo cosi generico come hai suggerito @migliorabile è davvero ottima, me l'appunto per usarla una volta che avrò definito tutti i modi di attaccare singolarmente (mi serve solo a me vederli uno per uno per avere un idea chiara).

    Per rispondere a @Spiritolibero: l'idea è che usi la struttura di Player per tutti i giocatori e, più avanti con calma, una seconda classe per i nemici (i famosi png) che quindi avranno dei method e propriety differenti ma sicuramente no attacco/difesa quindi si farò un interface per questo.

    Inoltre ho creato una classe che gestisce  le fasi del combattimento (quindi ad esempio quando il comba tinizia lo continua ad eseguire finchè uno dei 2 giocatori non muore (ovviamente poi l'idea è di implementare modi di fuggire o scegliere l'azione ma quello quando arriverò a studiare gli input).

    Grazie ancora molto per il vostro aiuto! 

  • Re: Dubbi su cascata di superclassi

    La risposta di @migliorabile è corretta. Vorrei aggiungere dei consigli che ti posson aiutare con problemi del genere.

    In una situazione del genere il punto di partenza è sempre quello di capire chi sono gli attori in gioco, nel tuo caso hai due Player, che possono essere mago, guerriero, ranger… e ragionare sul tipo di relazione che c'è tra di essi.

    Nel tuo caso, immagino che “Player” sia un'entità astratta, non qualcosa che realmente poi verrà usato perchè troppo generico.

    Potrebbe quindi avere senso pensare di utilizzare un'interfaccia per definire le funzionalità dei Player (metodo per attaccare, per difendere, fare magie…) e utilizzare questa interfaccia per definire le tue classi di gioco. Avrai quindi ad esempio la classe Guerriero che implementa la classe Player. Avendo elencato i metodi obbligatori che ogni player deve avere all'interno dell'interfaccia, nella classe dovrai fornirgli la corretta implementazione.

    Utilizzare l'interfaccia ti può anche aiutare a gestire i giocatori all'interno del codice. Ad esempio, non avrai bisogno di un array per i Guerrieri, uno per i Maghi… ma semplicemente un array di “Player”, perchè qualunque sia l'istanza dell'oggetto che peschi dall'array, questo ha sicuramente i metodi attacca e difendi definiti (anche se ognuno a modo suo).

    L'interfaccia potrebbe essere per esempio definita in questo modo:

    interface Player {
    	public void attack(Player defender);
    	public void defend(int damage, String attackType);
    }

    Poi ogni classe avrà la propria implementazione, tipo:

    class Guerriero implements Player {
    	
    	//... attributi ...
    	private int hp = 500;
    	private final int maxDamage = 100;
    	private final String attackType = "spada";
    	
    	public void attack(Player defender) {
    		int damage = (int) (Math.random() * maxDamage);
    		defender.defend(damage, attackType);
    	}
    	
    	public void defend(int damage, String attackType) {
    		//... gestisci l'attack type...
    		this.hp -= damage;
    	}
    }

    Per l'idea della superclasse (quindi una classe che viene ereditata da player) non ha molto senso, penso ti sia confuso con questo concetto :P

    La classe CombatSystem potrebbe essere una classe che non estende né implementa Player, ma semplicemente ha dei metodi per gestirli (tipo utilizzando un sistema a turni)  ad esempio un metodo del genere:

    class CombatSystem {
    
    	public void avviaCombattimento(Player attaccante, Player difensore) {
    		while(true) {
    			attaccante.attack(difensore);
    			
    			Thread.sleep(1000); // qui manca un throws o un try-catch
    		}
    	}
    }
  • Re: Dubbi su cascata di superclassi

    Ciao sh3dir grazie per la tua risposta , allora partiamo dalla fine:

    Si combatSystem alla fine lo sto usando per definire le meccaniche del gioco (nella fattispecie i method che gestiranno il combattimento (sto valutando anche l'idea del post combat. Nel costruttore accetta 2 player (per ora gestisco solo scontri 1v1 )

    per la superclasse Player invece non l'ho resa un interface perchè :

    tutte le sottoclassi hanno hp, caratteristiche, arraylist di armi , arraylist di equip etc etc. 

    Tutte le classi sanno attaccare e difendere come sanno cambiare arma impugnata etc etc.

    Quindi ho pensato che sarebbe una ridondanza per ogni sottoclasse (mago guerriero ranger etc ) dovergli rimettere tutte quelle proprietà e method.

    Mentre ho messo un method generico attacco speciale dentro la superclasse, perchè tutti avranno la possibilità di fare l'attacco speciale, e poi con un override correggo e specifico nelle sottoclassi cosa deve fare quel method.

    Perche ? in questo modo, la classe combatSystem accetta instance di Players avente attacco speciale e poi in base a che sottoclasse ho passato, fa attivare l'override per fare l'azione giusta. Almeno cosi lho pensata non so se ha un senso.

    Grazie mille! 

Devi accedere o registrarti per scrivere nel forum
5 risposte