Design orientato agli oggetti e corretta architettura Java per il mio programma

3

Questa è la prima volta che penso di voler creare un programma che usi davvero i principi OOP e voglio farlo nel modo più efficace ed efficiente.

Prima di tutto ci viene dato questo (ottimo) indovinello :

100 prisoners are imprisoned in solitary cells. Each cell is windowless and soundproof. There's a central living room with one light bulb; the bulb is initially off. No prisoner can see the light bulb from his or her own cell. Each day, the warden picks a prisoner equally at random, and that prisoner visits the central living room; at the end of the day the prisoner is returned to his cell. While in the living room, the prisoner can toggle the bulb if he or she wishes. Also, the prisoner has the option of asserting the claim that all 100 prisoners have been to the living room. If this assertion is false (that is, some prisoners still haven't been to the living room), all 100 prisoners will be shot for their stupidity. However, if it is indeed true, all prisoners are set free and inducted into MENSA, since the world can always use more smart people. Thus, the assertion should only be made if the prisoner is 100% certain of its validity.

Before this whole procedure begins, the prisoners are allowed to get together in the courtyard to discuss a plan. What is the optimal plan they can agree on, so that eventually, someone will make a correct assertion?

Quindi ho una soluzione e voglio creare un programma per eseguirlo. Voglio che il mio programma sia il più modulare possibile, nel senso che se trovo una soluzione migliore, non devo dover riscrivere tutto il mio codice. Penso che OOP sia davvero adatto per questo.

Ecco cosa ho fatto finora:

  • Una classe Principale : dove ho appena eseguito diversi giochi per testare le soluzioni
  • Una classe Gioco : che esegue solo un "tentativo". Ha un "carcere" (che è solo una schiera di prigionieri), un banco del giorno e altri oggetti utili.
  • E una classe Prisoner : che rappresenta un solo prigioniero.

Dopo aver riflettuto su questo, le uniche cose che un prigioniero può fare sono cambiare la luce dove sono stati scelti e affermare (o meno) che tutti sono venuti nella stanza .

Nella soluzione che ho trovato, ho due tipi su Prisoner. Quello che ho fatto è che ho appena implementato la mia classe Prisoner con il tipo più classico di Prisoner e ho creato una sottoclasse che semplicemente sovrascrive i metodi dalla classe Prisoner.

In questo momento, vedo due possibili miglioramenti se voglio riutilizzare il mio codice:

  • rende la classe Prisoner un'interfaccia Java, così che quando voglio creare un nuovo tipo, dovrei solo implementare un Prisoner. Ma il problema principale è che per lo più ho "prigionieri tipici", un sacco di persone che hanno lo stesso modello. Creo semplicemente un'implementazione 'Classic_Prisoner'?

  • creando una classe Behaviour che gestisce il comportamento a cui un Prigioniero ha dato una singola situazione. Ma non è solo lo stesso problema? Voglio dire che dovrei anche creare una sottoclasse Behavior per ogni tipo di Prisoner che sto considerando.

Che cosa fare per avere il codice più pulito lì ed essere in grado di riutilizzarlo quando arriva il momento?

    
posta Rivten 05.02.2014 - 10:49
fonte

2 risposte

3

Diversi "Behaviors" mi sembrano come il "strategia" modello (che inibisce un esempio per l'uso corretto dell'ereditarietà o l'utilizzo dell'interfaccia). Questo ti permetterà di cambiare facilmente il comportamento di ogni prigioniero in fase di esecuzione, cosa che non è facilmente possibile con diverse sottoclassi di Prigioniero.

Oltre a ciò, alla mia comprensione del tuo problema, tutti i Prigioni sono uguali (almeno dal punto di vista della gestione dei dati e dei comportamenti disponibili), quindi non penso che l'ereditarietà sia una buona idea per modellare oggetti Prisoner.

    
risposta data 05.02.2014 - 13:43
fonte
0

Cercherò di darti una risposta rapida ed efficiente. Non ti aiuterò a risolvere il problema, ma piuttosto a essere puramente tecnico sul tuo OOP.

Informazioni sulla classe Prisonner come interfaccia: no. Dovresti considerare l'ereditarietà. Se alcuni prigionieri sono "come prigionieri" ma con alcune nuove funzionalità, crea una classe WithSuchFeaturePrisoner che puoi anche memorizzare nel tuo array jail grazie al polimorfismo.

Behaviour tuttavia suona come un tipico nome dell'interfaccia . Se il comportamento dipende dal tipo di prigioniero, allora appartiene alla classe Prisoner come metodo. Solo per darti un'idea:

enum Situation {
  A,
  B,
  C
}

interface Behaviour {

  public void whatToDoWhen(Situation happens);

}

class LazyPrisoner implements Behaviour {

  public void whatToDoWhen(Situation happens) {
    // I do nothing
  }

}

Non ho pensato all'intero problema - e ne ho fatto astrazione - perché voglio lasciarvi la soddisfazione di risolverlo da soli (e diamine, anch'io sono LazyStackExchangeUser ), ma io spero che questo aiuti.

    
risposta data 05.02.2014 - 11:43
fonte

Leggi altre domande sui tag