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 :slight_smile:

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

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 :expressionless:

Any ideas?

Merc.

Begin forwarded message:

Hi,

OK thanks James!

(The list of book I have to read is getting dangerously long…!)

Merc.

Tony M. wrote:

Hello people,

As some of you know, I would like to start “thinking” in objects. So, I
am trying to study some patterns.

Patterns may make little sense if you’ve no experience with OO. Simply
knowing a pattern isn’t enough to help you determine appropriate use.

Consider looking at

Designing Object-Oriented Software, by Rebecca Wirfs-Brock

Agile Software Development, by Robert C. Martin


James B.

“A principle or axiom is of no value without the rules for applying it.”

  • Len Bullard

Yeah, I didn’t finish my sentence there, d’oh (need a way to edit
mailing list messages).

I personally think that by focusing on what an Object can do and how
it behaves in a system and sort of putting what it stores on the
backburner (until you need to think about it) can help make it easier
to think about programming in an Object Oriented style.

Well, the thing is that the AbstractSessionPattern in Ruby looks
suspiciously like a Factory pattern. The Server is customizing
instances of Session objects which it is returning.

It’s probablly a fair bit different looking for statically typed
languages.

OO thinking isn’t going to come through reading patterns. Patterns
help you recognize how and where you can apply a solution that’s
already been vetted when you’re designing/coding.

Thinking in terms of Objects will come very naturally as you gain more
experience.

On the other hand, you might find it a little easier if you thought of
Objects as Actors instead (that might get confusing though since Actor
systems are closely related and a little different than Object
systems). I personally think that by focusing on what an Object can
do and how it behaves in a system and sort of putting what it stores
on the backburner (until you need to think about it).