OOP Design - Possível abordagem errada torna impossível implementá-lo em código

5

Neste último semestre eu tive palestras sobre design OOP, eu entendi mais do que eu deveria mas há algo que não consigo acertar.

Tenho certeza de que os modelos que eu crio estão errados porque não podem ser implementados. Eu escrevi bastante porque não sei dizer onde está o problema.

Isso não é lição de casa, é uma amostra de um problema do ano passado.

Um exemplo: Crie um "Stackoverflow" para uma aula.

Caso de uso: postando uma pergunta

pré-condições: Existe um aluno autenticado

pós-condições: a pergunta foi gravada e todos que conseguiram ler a questão foram notificados.

Cenário:

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

Os passos 6,7 podem ser repetidos até que o usuário diga que acabou.

Existem extensões, mas não necessárias para demonstrar o meu problema.

Como eu faria: Diagrama de Sequência do Sistema

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

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

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

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

O modelo de domínio teria: Aluna Classe Instrutor Questão Tag StudentCatalog InstructorCatalog

As relações entre as outras são simples (eu acredito) é por isso que eu não estou esboçando isso.

Percebi meu problema ao criar o diagrama de interação para este caso de uso.

Eu decidi que o controlador de caso de uso seria uma classe "manipuladora" composta QuestionHandler, então os dois primeiros diagramas de interação eu acredito ser algo como:

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!)

O problema real:

De tudo isso, imagino que o código seja:

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

E não consigo ver isso funcionando assim, meu problema de onde "submitBody (bodytext)" obtém a pergunta atual?

Como faço para lidar com o "contexto" de cada caso de uso, o que, nesse caso, faria com que ele ficasse confuso (é assim que me parece) e use os valores de retorno para fazê-lo funcionar.

Mas e se eu tiver um "contexto" de casos de uso que precise de muitas coisas para mim mudar e mudar de lugar?

Estou totalmente perdido, achei que ia resolver a si mesmo, mas acontece que não dá para ver como as coisas seriam implementadas com esse problema.

    
por Zentdayn 11.06.2013 / 03:52
fonte

1 resposta

5

Objetos transportam estado. Um diagrama de seqüência não transmite esse estado, mas seus objetos manterão o estado entre os pedidos. Você pode ir além e transmitir o estado como um argumento de método, como em submitBody(bodyText, session) , mas isso é um pouco perigoso, pois convida a programação de estilo procedural, se você pretende simplesmente traduzir isso em código.

Em vez disso, eu aceitaria que o seu caso de uso e os diagramas de estado tivessem algum nível de abstração neles e não precisassem transmitir todos os detalhes. Os detalhes do seu objeto não vêm inteiramente de diagramas.

Olhando para o vocabulário do seu domínio, você deve ter um tipo ao longo das linhas de Question que constrói seu estado de forma iterativa à medida que mais informações são dadas a ele por meio de chamadas de método para ele. Como já foi dito, esse objeto seria mantido como estado entre solicitações, um cenário típico em interações de estilo de fluxo de trabalho, como a que você descreve aqui.

Feira suficiente?

    
por 11.06.2013 / 04:43
fonte