Millies, Sebastian wrote:
-----Original Message-----
From: Simon Nash [mailto:[email protected]]
Sent: Thursday, December 09, 2010 10:20 AM
To: [email protected]
Subject: Re: Elementary question about Scopes
Millies, Sebastian wrote:
Yes, I see the point about callbacks.
With regard to the other, cosmetic differences, what you regard as
ugly, I
regard as good programming practice. To me, instance variables
represent the
state of an object, in particular mutable state. If there is no such
state,
I find it much clearer to pass parameters as method arguments rather
than
to store them in instance variables.
With STATELESS scope, the object instance == the individual service
request.
Therefore it is completely appropriate to store data relating only to
the
individual request as instance variables of this object.
Simon
[snip]
I believe it's only a matter of taste.
>
Agreed. However, as SCA provides STATELESS scope, I think it's reasonable
for me to attempt some justification for its existence :-)
After all, all the "data relating
only to the individual request" already come in as service method parameters.
These are just the initial values. Any further data computed as part of
processing the individual request needs to be stored somewhere. If this
processing involves multiple methods of the implementation object, it seems
useful and appropriate (to me) to store these intermediate results in
instance variables.
As different methods have different parameter sets, copying the top-level
method parameters to instance variables makes for code which I find hard to
read, because in methods lower in the call hierarchy, I cannot easily see
which part of that "request state" is really relevant.
In contrast, I can see that immediately from a method signature, when all
relevant parameters are threaded through the call tree.
For a straight pass-through of input parameters, this makes sense to me.
For sharing intermediate computation results between multiple methods of
the same instance object, I would find it very cumbersome to arrange
all my method signatures to make sure the necessary data is passed around.
Also, the approach you're suggesting has the issue of introducing a redundant
COMPOSITE scoped instance which has no apparent useful purpose. This object
has no mutable state, because all mutable state is stored in method local
variables that are passed around as parameters. This seems strange, as the
purpose of COMPOSITE scope in SCA is to provide mutable state that's shared
between requests. Using it for this other purpose means that people who
read the code and see the scope declared as COMPOSITE are likely to find it
harder to understand whether the service has stateful or stateless semantics.
Simon
-- Sebastian
