Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
I don't think this question match for design-patterns tag. –  Fendy Jun 11 '13 at 4:39
add comment

migrated from stackoverflow.com Jun 11 '13 at 11:28

This question came from our site for professional and enthusiast programmers.

1 Answer

up vote 4 down vote accepted

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?

share|improve this answer
    
So i would have something that is a Question being built, ok. But how would i carry this across requests? Have it as a attribute in QuestionHandler? –  Zentdayn Jun 11 '13 at 3:16
    
You have to store the state in session somewhere. On the client or on the server (they could be the same). So that when making subsequent requests the state can be retrieved. If this a standalone application it could be as simple as having a class variable. –  Seth M. Jun 11 '13 at 12:55
    
Seth is correct. In web environments, the place to store this information is the session, not the handler. Handlers tend to be rather stateless. (In a single user desktop application it doesn't matter as much.) Web frameworks come with their own session management, but nothing prevents you from rolling your own, or even extending the framework's capabilities, for example by storing session in a relational database. –  Mihai Danila Jun 11 '13 at 15:00
    
So a class variable would be the solution for lets say a desktop application ( but wouldn't this make the handler have a state ?) But if we talking about some other environment where client and server are no the same storing the state of what we are doing should not be in Handlers. –  Zentdayn Jun 12 '13 at 11:36
    
Desktop applications are typically (if not always) single user applications. In such applications, it is not as important for your handlers to be stateless. They can still be, depending on the kind of purism that you have a sweet tooth for. For the second part, of course, if your handler only stores state, then it is more a Repository (as in the pattern). But in a web application handlers are there to receive commands in the form of web requests, so handlers may well be warranted. Your browser could also call straight into web services, so your handlers are on your client - now a fat client. –  Mihai Danila Jun 12 '13 at 18:21
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.