OOP Design - Possible wrong approach makes it impossible to implement it in code

Question

This last semester i've had lectures about OOP design, i understood most of what i was supposed to
but there is something that i can't get right.

I'm pretty sure that the models i create are wrong because they cannot be implemented. I wrote quite a lot because i can't tell where the problem is.

This isn't homework , it is a sample of a problem from the past year.

An example: Design a "Stackoverflow" like thing for a class.

Use case: Posting a question

pre-conditions: There is a authenticated student

pos-conditions: The question was recorded and everyone that can read the question has been notified.

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

Steps 6,7 can be repeated until the user tells us he's done.

There are extensions but not necessary to demonstrate my problem.

How would i do it: System Sequence Diagram

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

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

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

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

The domain model would have: Student Class Instructor Question Tag StudentCatalog InstructorCatalog

The relations between each other's are simple ( i believe ) thats why i'm not sketching it up.

I noticed my issue when making the interaction diagram for this use-case.

I decided that the use-case controller would be a made up "handler" class QuestionHandler so the first two interaction diagrams i would believe to be something like:

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

The actual problem:

From all this i imagine the code to be:

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

And i can't see this working like this, my problem where does "submitBody(bodytext)" gets the currentQuestion from?

How do i handle the "context" of each use-case, which in this case i would make it messy ( that's how it feels to me) and use the return values to make it work.

But what if i have a use-case "context" that requires lots of things to me change and moved around?

Im totally lost, i thought it would solve itself but it turns out o can't see how things would be implemented with this issue.

Answer 1

Objects carry state. A sequence diagram doesn't convey this state, but your objects will keep state in between requests. You could go further and transmit the state as a method argument, as in submitBody(bodyText, session), but this is a bit dangerous in that it invites procedural style programming if you intend to simply translate this into code.

Instead, I would accept that your use case and state diagrams have some level of abstraction in them and they don't need to convey all the details. Your object details doesn't come entirely from diagrams.

Looking at the vocabulary of your domain, you should have a type along the lines of Question that constructs its state iteratively as more information is given to it by way of method calls into it. As stated already, this object would be maintained as state across requests, a typical scenario in workflow style interactions such as the one you describe here.

Fair enough?