Archive from 27_6_07 - Task Objects

Just musing on OOD and looking at all the books on my desk. Some of the ideas I have about the way to apply objects seems to be beyond the scope of the books ability to conceptualize.

I see objects being used to encapsulate the concepts in the domain, not just the structural concepts but the ephemeral concepts. None of the books have yet made this kind of link for me. I am hoping one of them will already have covered the material so I don't have to explain it all. Maybe they are explaining it in their own way, I am just not getting it.
I have restricted my reading to only books published since 2000. Along with a couple of well referenced ones from before that. My hope is that the more recent authors will have "gotten" it and be more on top of explaining OO. So far its just more of the same. Some have clever ways or pretty explanations but they all tread a similar path. if you substitute the concept of ADT (abstract data types) where they use the term Object, it still makes the same amount of sense. Build the static structure of the app, pass data around in response to events(or messages), exit the app. Etc.
The true power of object oriented design is the ability for objects to encapsulate both the fine grained semantics of the domain as well as the dynamic activities. I believe that the relationship between Use cases and the object design is not nearly as direct as it should be. Each Use case should be reflected with a 1:1 relationship with an object in the design. Obviously these are objects that express a dynamic concpet. They are instantiated on demand, encapsulate the concept of the task being performed and then are deleted once the task has terminated or succeeded.
These objects would be instantiated with parameters of all the structural objects they needed to interact with. This removes the need for all the structural objects to be interwoven with pointers and references to each other, to the extent that (I) have traditionally done, to get the app to work.
There will still need to be a common pool of pointers to the structural objects that can then have some factory method which creates these dynamic objects and sets them up with the correct references. Fairly easy once the Interfaces are defined.
Anyway, back to work.

Edit.

This kind of dynamic expression will render sequence diagrams practically irrelevant. They now are just expressing the internal (encapsulated) concepts within the constructor of a dynamic object. They are probably still excellent for expressing the actual sequence of the calls, just not in the way I have been thinking of them to this point. So to re-cap, this is probably more about me finally "getting" it than everyone else not "getting" it. All I need now is a book that expresses this and is available from one of the big distributors. Please....