From: Tony Mobily <merc@...>
Date: 2006-02-22T22:37:28+09:00
Subject: New to OOP and Abstract Session Pattern

Hello people,

As some of you know, I would like to start "thinking" in objects. So,  
I am trying to study some patterns.
I've actually ordered a book (suggested in this list!). However...  
well, you know :-)

I am having a bit of a problem understanding the Abstract Session  
Pattern.

http://rubygarden.org/ruby/ruby?AbstractSessionPattern

Does anybody here know WHY and HOW you'd use it?

Here is the email I sent to the author of the document above -  
unfortunately, I never got an answer. I assume he must get a lot of  
emails like this :-|

Any ideas?


Merc.

Begin forwarded message:

> From: Tony Mobily <merc@mobily.com>
> Date: 21 February 2006 8:22:07 AM
> To: XXXXXXXXX
> Subject: New to OOP and Abstract Session Pattern
>
> Hello XXXXXXXX,
>
> First of all, thank you for your help with documenting Ruby.
>
> I am not an OO expert. In fact, I'm only just starting. I've  
> learned Ruby (that was the easy part). Now, I am trying to learn  
> how to *design* things properly in Ruby.
>
> I am going through the "Patterns" in RubyGarden, and I've come  
> across yours: AbstractSessionPattern.
>
> I've tried to read http://www.doc.ic.ac.uk/~np2/patterns/ 
> session.pdf, and frankly, I simply can't understand what they are  
> on about :-| A great justification for the whole pattern is typing.  
> Typing is one of the many reasons I refused to learn Java and C++...
>
> Here is what I understand from the code itself:
>
> * The Server class has the method "session" which returns an  
> Session object. The Session object at the same time is passed  
> "self", which represents the Server.
>
> * Session obviously stores the server's class. As a bonus, it gets  
> its ID. For what I gather, the ID is only handy to differentiate  
> amongst clients.
>
> * The method Server#service_client cannot really be used by a  
> Server object directly, because it needs a Session object to do  
> anything
>
> * A Session object can run #Server@service_client, which will be  
> made aware of what object it should work on.
>
> * A Session object can effectively run *any* method in the Server  
> object from which it was created. This is the bit that confuses me  
> the most. Wasn't this supposed to be "safe"?
>
> * A Session object doesn't "know" what clients connected to it. I  
> don't see a way for the Server to call a method in all of the  
> Session objects created by it.
>
> * I think I am going bananas
>
> The problem is that I understand what the code does, but I am  
> unable to see teh "big picture" - or the pattern's "point".
> I guess my real question is in the pattern definition:
>
> "The Abstract Session pattern provides a way for an object to store  
> per-client state without sacrificing type-safety or efficiency."
>
> In the example you provided, which object is storing per-client  
> states? And which are the clients here?
>
> What's a *practical* scenario for such a pattern?
>
> Thanks a lot for your help!
>
> Merc.