Object Lifetime/Association vs Uses
- From: "kurbylogic@xxxxxxxxxxx" <kurbylogic@xxxxxxxxxxx>
- Date: 14 Jan 2007 18:28:11 -0800
I've been pondering the question about how association and uses affects
object lifetime. It seems that very few books talk much about the
creational aspects of an application; most sequence diagrams always
assume objects already exist with the nessessary relationships already
established.
Receintly, I read a book Event Based Programming: Taking Events to the
Limit. I really like the wiring diagrams that he uses. I noticed that
he establishes most all of the relationships during application start
up, with relatively few classes created during the lifetime of the
application.
I'm thinking perhaps I make too much use of class attributes, and not
enough use of parameters; often times when I find redundant parameters,
I make them attributes of the class. However, as a result, I often
find myself delaying creation of the class until I have all the
necessary attributes; thus I am unable to establish relationships until
sometime later.
I'm not entirely sure how to phrase my question; I'm wondering if there
are any guidelines regarding how context specific an object should be.
There are three factors I'm currently concidering: state, identity, and
behavioral differences. For example, if I had a gateway class to
connect to another system which requires system name, username and
password. I might choose to create one gateway instance per system or
one gateway per user. As far as state is concerned, the gateway will
probably need to estabish seperate connections for each user;
additionally, there might even be a transactional scope. As an
abstract rather then concrete object, identity is a little more vague,
it could be the system name or system name+user: if one per user, there
would be only one active transactional state or such state would need
to be externalized; if per system name, user and transactional state
would need to be externalized. In regards to behavioral differences,
the gateway implementation is not likely to vary based on username or
event system name, so perhaps, there should only be one instance per
system type--in such case, the differences between types is probably so
significant that each system type would likely have a seperate class
entirely--and such an instance could be a singleton. The less context
specific the object is the more parameters would be required for each
method: now the client must specify system name, user name, password
and transaction; the parameters might be grouped into a parameter
object--perhaps named connection--but the gateway would no longer be
able to store system, user, and transaction specific state as local
variables; such state would need to be externalized perhaps stored in a
map based on the provided parameter object. However, the advantage of
the latter is that the relationships could be established much earlier;
making it much easier centralize when, where, how, and which objects
are created and wired together. Up until now I have leaned more
towards state as the determining factor in how long an object should
live; however, I'm now beginning to think that behavioral differences
are most important, despite additional parameters and not being able to
store state as local variables.
What do you think?
- Kurt
.
- Follow-Ups:
- Re: Object Lifetime/Association vs Uses
- From: H. S. Lahman
- Re: Object Lifetime/Association vs Uses
- From: Matt McGill
- Re: Object Lifetime/Association vs Uses
- Prev by Date: Re: Simples Rules make creating Big Balls of Mud impossible.
- Next by Date: Latency Requirements vs Architecural Level, is there a Design Principle in there?
- Previous by thread: Encapsulation vs Extensibility
- Next by thread: Re: Object Lifetime/Association vs Uses
- Index(es):
Relevant Pages
|
