Prev: showing progress of some processing
Next: FINALLY: Another language adopts Smalltalk's keyword -syntax
From: Daniel T. on 27 Dec 2007 11:14
Veloz <michaelveloz(a)gmail.com> wrote:

> Thanks for continuing with this thread, I am learning from our
> discussion..:-)

No problem.

> > That said, what is A good for? If all A does is iterate through the list
> > it contains, then it adds no value. In order for A to have value, it
> > must provide something that the simple list can't provide. It must have
> > an invariant.
>
> I'm not totally sure what you mean by "invariant" here..

There must be some relationship among its parts that it ensures is
always true.

> but:
>
> In our case, A is the Test Product class and what it provides, above
> and beyond containing list of Feature Groups, is the knowledge of how
> to provide a total price, given access to the Feature Groups and some
> additional data we have not talked about. So I guess that's what "A is
> good for"... Also, it knows how to provide a de-duped list of features
> from across the Feature Groups it contains.

That last bit is important! A TestProduct can't let just anybody
add/remove/modify FeatureGroups from its list, because if it does, then
it can't ensure that there are no duplications of Features across
FeatureGroups.

> > Once you give A some value (expressed as an invariant,) then it is easy
> > to see that you can't let just anybody add/remove/change items in the
> > list (i.e., you can't expose the list) because that would make it
> > impossible for A to ensure its invariant.
>
> Hmm. Interesting. As it currently stands, A doesn't much care who adds/
> deletes features from the feature groups, or who adds/deletes feature
> groups from the Test Product (A)...

Wait, this is different than what you said above. So, for example (in
Python):

#assume 'features' is a list of Features in a FeatureGroup
featureGroupA.features.append( myFeature )
featureGroupB.features.append( myFeature )
#assume 'featureGroups' is a list of FeatureGroups in a TestProduct
myTestProduct.featureGroups.append( featureGroupA )
myTestProduct.featureGroups.append( featureGroupB )

Does the above cause a problem or not?

> at the point of being asked to
> calc the cost, it iterates over whatever feature groups are currently
> contained in it and asks them for their price as of that point in
> time. To this, it adds some other amounts the come from elsewhere.
>
> So from this perspective, A doesn't need to "protect" the list of the
> Feature Groups or the content of the Feature Groups. ... Makes me
> wonder how strong the association between A and B really is. If A
> doesn't care what's in the B (the list of Feautre Groups) then....
> then ... then what??

Then A is just a data-bucket. You are working in what Robert Martin
called "the representational paradigm"

Objects present an /abstract behavioral/ interface that hides the
underlying representation... On the other hand, representations
present /concrete static/ interfaces that are devoid of significant
behavior.

-- Martin, Robert. "Designing Object-Oriented C++ Applications Using the
Booch Method", 1995
From: Veloz on 27 Dec 2007 13:52
On Dec 27, 11:14 am, "Daniel T." <danie...(a)earthlink.net> wrote:
> Veloz<michaelve...(a)gmail.com> wrote:
> > Thanks for continuing with this thread, I am learning from our
> > discussion..:-)
>
> No problem.
>
> > > That said, what is A good for? If all A does is iterate through the list
> > > it contains, then it adds no value. In order for A to have value, it
> > > must provide something that the simple list can't provide. It must have
> > > an invariant.
>
> > I'm not totally sure what you mean by "invariant" here..
>
> There must be some relationship among its parts that it ensures is
> always true.
>
> > but:
>
> > In our case, A is the Test Product class and what it provides, above
> > and beyond containing list of Feature Groups, is the knowledge of how
> > to provide a total price, given access to the Feature Groups and some
> > additional data we have not talked about. So I guess that's what "A is
> > good for"... Also, it knows how to provide a de-duped list of features
> > from across the Feature Groups it contains.
>
> That last bit is important! A TestProduct can't let just anybody
> add/remove/modify FeatureGroups from its list, because if it does, then
> it can't ensure that there are no duplications of Features across
> FeatureGroups.
>
> > > Once you give A some value (expressed as an invariant,) then it is easy
> > > to see that you can't let just anybody add/remove/change items in the
> > > list (i.e., you can't expose the list) because that would make it
> > > impossible for A to ensure its invariant.
>
> > Hmm. Interesting. As it currently stands, A doesn't much care who adds/
> > deletes features from the feature groups, or who adds/deletes feature
> > groups from the Test Product (A)...
>
> Wait, this is different than what you said above. So, for example (in
> Python):
>
> #assume 'features' is a list of Features in a FeatureGroup
> featureGroupA.features.append( myFeature )
> featureGroupB.features.append( myFeature )
> #assume 'featureGroups' is a list of FeatureGroups in a TestProduct
> myTestProduct.featureGroups.append( featureGroupA )
> myTestProduct.featureGroups.append( featureGroupB )
>
> Does the above cause a problem or not?
>
> > at the point of being asked to
> > calc the cost, it iterates over whatever feature groups are currently
> > contained in it and asks them for their price as of that point in
> > time. To this, it adds some other amounts the come from elsewhere.
>
> > So from this perspective, A doesn't need to "protect" the list of the
> > Feature Groups or the content of the Feature Groups. ... Makes me
> > wonder how strong the association between A and B really is. If A
> > doesn't care what's in the B (the list of Feautre Groups) then....
> > then ... then what??
>
> Then A is just a data-bucket. You are working in what Robert Martin
> called "the representational paradigm"
>
> Objects present an /abstract behavioral/ interface that hides the
> underlying representation... On the other hand, representations
> present /concrete static/ interfaces that are devoid of significant
> behavior.
>
> -- Martin, Robert. "Designing Object-Oriented C++ Applications Using the
> Booch Method", 1995

Interesting.... I guess TestProduct is not "invariant" with respect to
the "list of Feature Groups", then.

Test Product's two main responsibilities (providing a de-dupped list
of features, and producing a "grand total cost") could each be coded
as methods (even static ones) that takes a list of Feature Groups as a
parameter. If someone alters this list a few moments later, these
same methods could be called again to produce an "updated" list of de-
duped features and a new grand total.


The reason I have Test Product holding a reference to the list of
Feature Groups is because of the whole/part thing.. It would seem odd
to just have these lists of Feature Groups floating out there in my
application and then have some code pass them as parameters to
something like
TestProductHelper.GetDeDupedFeatureList(FeatureGroupList) and
TestProductHelper.GetGrandTotal(FeatureGroupList,AdditionalCosts).

I dunno.. maybe it wouldn't be so odd.... Test Product has only
"behavior" from what I just said. It doesn't really have "identity" in
the way we normally think about it.. The identity comes from the
list of Feature Groups (indirectly)

But then again, from the user expects to assign names to test products
sometimes.. So now I would need to somehow associate a name property
with each list of Feature Groups...feels like I'm creeping back to an
object that *has* a list, plus some other attributes.. I feel like
I'm going in circles here LOL

M

From: Daniel T. on 27 Dec 2007 18:02
Veloz <michaelveloz(a)gmail.com> wrote:

> Interesting.... I guess TestProduct is not "invariant" with respect to
> the "list of Feature Groups", then.
>
> Test Product's two main responsibilities (providing a de-dupped list
> of features, and producing a "grand total cost") could each be coded
> as methods (even static ones) that takes a list of Feature Groups as a
> parameter. If someone alters this list a few moments later, these
> same methods could be called again to produce an "updated" list of de-
> duped features and a new grand total.
>
> The reason I have Test Product holding a reference to the list of
> Feature Groups is because of the whole/part thing.. It would seem odd
> to just have these lists of Feature Groups floating out there in my
> application and then have some code pass them as parameters to
> something like
> TestProductHelper.GetDeDupedFeatureList(FeatureGroupList) and
> TestProductHelper.GetGrandTotal(FeatureGroupList,AdditionalCosts).
>
> I dunno.. maybe it wouldn't be so odd.... Test Product has only
> "behavior" from what I just said. It doesn't really have "identity" in
> the way we normally think about it.. The identity comes from the
> list of Feature Groups (indirectly)
>
> But then again, from the user expects to assign names to test products
> sometimes.. So now I would need to somehow associate a name property
> with each list of Feature Groups...feels like I'm creeping back to an
> object that *has* a list, plus some other attributes.. I feel like
> I'm going in circles here LOL

That's fine, but the TestProduct isn't an object in the OO sense of the
word. It's just a data bucket. In C++, I would make it a struct, not a
class.
First  |  Prev  | 
Pages: 1 2 3 4
Prev: showing progress of some processing
Next: FINALLY: Another language adopts Smalltalk's keyword -syntax