Progettazione OOP - Un possibile approccio errato rende impossibile l'implementazione in codice

5

Quest'ultimo semestre ho tenuto lezioni sul design OOP, ho capito la maggior parte di ciò che dovevo fare ma c'è qualcosa che non riesco a capire.

Sono abbastanza sicuro che i modelli che creo sono sbagliati perché non possono essere implementati. Ho scritto parecchio perché non riesco a capire dove sia il problema.

Questo non è compito a casa, è un esempio di un problema dell'anno scorso.

Un esempio: Disegna una cosa simile "Stackoverflow" per una classe.

Caso d'uso: pubblicare una domanda

precondizioni: c'è uno studente autenticato

condizioni pos: la domanda è stata registrata e tutti coloro che possono leggere la domanda sono stati avvisati.

Scenario:

1. The student tells the system he wants to submit a question and supplies the title
2. The system asks for the question body.
3. The student submits the question body.
4. The system records this.
5. The system reports all used question tags on that student's class.
6. The student submits the choosen question tag
7. The system records everything and reports the used tags
8. The student tells if he wants the question to be public
9. The system records everything and notifies the people it should

I passaggi 6,7 possono essere ripetuti fino a quando l'utente ci dice che ha finito.

Ci sono estensioni ma non è necessario dimostrare il mio problema.

Come potrei farlo: Diagramma di sequenza del sistema

newQuestion(title)
------------------>

OK
<------------------

submitBody(bodytext)
------------------->  _
                      | LOOP
Existing tags         |
<-------------------  |
                      |
choosetag(tag)        |
------------------->  |
                      _
chooseVisibility(b)                        
------------------->

OK
<-------------------

Il modello di dominio avrebbe: Alunno Classe Istruttore Domanda Etichetta StudentCatalog InstructorCatalog

Le relazioni tra di loro sono semplici (credo) questo è il motivo per cui non lo sto delineando.

Ho notato il mio problema durante la creazione del diagramma di interazione per questo caso d'uso.

Ho deciso che il controllore del caso d'uso sarebbe una classe "handler" composta da QuestionHandler, quindi i primi due diagrammi di interazione credi di essere qualcosa tipo:

newQuestion(title)
 - it has to create a question with the proper title title
 submitBody(bodytext)
 - it has to set bodytext has the text for the question we are creating ( and i don't know where it is!)

Il vero problema:

Da tutto ciò immagino che il codice sia:

class QuestionHandler
 method postQuestion(title) {
  newQuestion(title);
  submitBody(bodytext);
  ... etc
 }

E non riesco a vedere questo funziona in questo modo, il mio problema, da dove "submitBody (bodytext)" ottiene la currentQuestion?

Come gestisco il "contesto" di ogni caso d'uso, che in questo caso lo renderei disordinato (è così che mi sento) e usare i valori di ritorno per farlo funzionare.

Ma cosa succede se ho un "contesto" del caso d'uso che richiede molte cose per me cambiare e spostarmi?

Sono completamente perso, ho pensato che si sarebbe risolto da solo, ma non è stato in grado di vedere come sarebbero state implementate le cose con questo problema.

    
posta Zentdayn 11.06.2013 - 03:52
fonte

1 risposta

5

Gli oggetti portano lo stato. Un diagramma di sequenza non comunica questo stato, ma i tuoi oggetti manterranno lo stato tra le richieste. Potresti andare oltre e trasmettere lo stato come argomento del metodo, come in submitBody(bodyText, session) , ma questo è un po 'pericoloso in quanto invita la programmazione in stile procedurale se intendi semplicemente tradurre questo in codice.

Invece, accetterei che i diagrammi del caso d'uso e dello stato presentassero un certo livello di astrazione e non hanno bisogno di trasmettere tutti i dettagli. I dettagli dell'oggetto non provengono interamente dai diagrammi.

Osservando il vocabolario del tuo dominio, dovresti avere un tipo lungo le linee di Question che costruisca il suo stato in modo iterativo man mano che maggiori informazioni vengono fornite tramite chiamate al metodo in esso. Come già detto, questo oggetto sarebbe mantenuto come stato tra le richieste, uno scenario tipico nelle interazioni di stile del flusso di lavoro come quello che descrivi qui.

Giusto abbastanza?

    
risposta data 11.06.2013 - 04:43
fonte

Leggi altre domande sui tag