| View previous topic :: View next topic |
| Author |
Message |
Dave Fowler
Guest
|
 Posted: Thu Feb 05, 2004 11:09 am Post subject: Object attributes and notifications |
 |
|
How do people here keep their business objects aware of changes to their
attributes? My business objects derive from an TObjectAttribute class which
contains a list of IAttribute interface references. Attributes are derived
from a TAttribute class which implements and IAttribute interface.
TObjectAttribute itself derives from TAttribute. The TAttribute class also
implements the ISubject interface so the observer pattern would seem to be
the way to go. However, the class I use to implement ISubject contains a
reference counted list of Observers so making the business object an
observer of its attributes would mean that it would never be freed due to
cross referencing. I thought of creating an new implementation of ISubject
which holds only weak references to its observers as one solution. Does
anyone else have any better ideas?
Hope this makes sense,
TIA
Dave
|
|
| Back to top |
|
 |
Bob Dawson
Guest
|
| Posted: Thu Feb 05, 2004 1:58 pm Post subject: Re: Object attributes and notifications |
|
|
"Dave Fowler" wrote
| Quote: | How do people here keep their business objects aware of changes
to their attributes?
|
I must be missing something--are the internal attributes of the business
object publicly exposed? That would be a serious design error in my
view--only the object itself has the right to touch its members (whether
they're implemented directly as fields,or as attribute objects is
irrelevant).
So why does an owning BO require notification that an internal attribute has
changed when it should be the only thing able to change it? If I have a
method
TMyBO protected procedure SetAge(const Value : integer);
then anything that needs to happen when the Age attribute is set should
simply be called in that method (including possibly the BO running its
subscriber list).
| Quote: | [...] The TAttribute class also
implements the ISubject interface so the observer pattern would
seem to be the way to go.
|
Again I see this as a containment problem: BOs can be ISubjects (as above),
but nothing outside the BO has any right to observe the BOs private parts
directly.
bobD
|
|
| Back to top |
|
|
Ken Revak
Guest
|
| Posted: Thu Feb 05, 2004 3:18 pm Post subject: Re: Object attributes and notifications |
|
|
I too struggled with this one. My solution is that the attributes have
a weak reference to their "owner". When they change, they fire of an
ItemChanged(self) call to the owner.
In truth a base class contains a list of IAttribute interfaces; this
interface reference keeps the attributes alive. The application level
parts contain pointers to the TAttributeInt class rather than
IAttributeInt. This permits the "owning" object to have more direct
access to the implementation of the attribute while externally exposing
limited information via interfaces.
Ken Revak
Lethbridge, AB
Dave Fowler wrote:
| Quote: | How do people here keep their business objects aware of changes to their
attributes? My business objects derive from an TObjectAttribute class which
contains a list of IAttribute interface references. Attributes are derived
from a TAttribute class which implements and IAttribute interface.
TObjectAttribute itself derives from TAttribute. The TAttribute class also
implements the ISubject interface so the observer pattern would seem to be
the way to go. However, the class I use to implement ISubject contains a
reference counted list of Observers so making the business object an
observer of its attributes would mean that it would never be freed due to
cross referencing. I thought of creating an new implementation of ISubject
which holds only weak references to its observers as one solution. Does
anyone else have any better ideas?
Hope this makes sense,
TIA
Dave
|
|
|
| Back to top |
|
|
Ken Revak
Guest
|
| Posted: Thu Feb 05, 2004 3:22 pm Post subject: Re: Object attributes and notifications |
|
|
I believe Dave is referring to a situation where you have objects that
implement the attributes and then publish the attribute object/interface
as the property. (Not the classic property Age : integer read FAge write
SetAge scheme)
Ken Revak
Lethbridge, AB
Bob Dawson wrote:
| Quote: | "Dave Fowler" wrote
How do people here keep their business objects aware of changes
to their attributes?
I must be missing something--are the internal attributes of the business
object publicly exposed? That would be a serious design error in my
view--only the object itself has the right to touch its members (whether
they're implemented directly as fields,or as attribute objects is
irrelevant).
So why does an owning BO require notification that an internal attribute has
changed when it should be the only thing able to change it? If I have a
method
TMyBO protected procedure SetAge(const Value : integer);
then anything that needs to happen when the Age attribute is set should
simply be called in that method (including possibly the BO running its
subscriber list).
[...] The TAttribute class also
implements the ISubject interface so the observer pattern would
seem to be the way to go.
Again I see this as a containment problem: BOs can be ISubjects (as above),
but nothing outside the BO has any right to observe the BOs private parts
directly.
bobD
|
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Thu Feb 05, 2004 4:14 pm Post subject: Re: Object attributes and notifications |
|
|
"Ken Revak" wrote
| Quote: | I believe Dave is referring to a situation where you have
objects that implement the attributes and then publish the
attribute object/interface as the property. (Not the classic
property Age : integer read FAge write SetAge scheme)
|
Quite possible--but in my view that would still be a mistake; I regard
AttributeItems as an internal implementation detail that should not be
exposed. From my perspective, "property Age : integer" is the preferred form
of exposure regardless of whether Age is implemented internally as a field,
an attribute object, or a calculation. The relation between internal members
and public properties is not a 1::1 affair.
bobD
|
|
| Back to top |
|
|
Dave Fowler
Guest
|
| Posted: Thu Feb 05, 2004 4:33 pm Post subject: Re: Object attributes and notifications |
|
|
"Ken Revak" <NOSPAM_ken.revak (AT) telusplanet (DOT) net> wrote
| Quote: | I believe Dave is referring to a situation where you have objects that
implement the attributes and then publish the attribute object/interface
as the property. (Not the classic property Age : integer read FAge write
SetAge scheme)
That's about right, specifically when the attribute is itself an object |
attribute. I want the owning object attribute to be notified when any
attributes of the owned object attribute change.
|
|
| Back to top |
|
|
Ken Revak
Guest
|
| Posted: Thu Feb 05, 2004 4:40 pm Post subject: Re: Object attributes and notifications |
|
|
In your view you are correct. I prefer my reality.
Ken Revak
Bob Dawson wrote:
| Quote: | "Ken Revak" wrote
I believe Dave is referring to a situation where you have
objects that implement the attributes and then publish the
attribute object/interface as the property. (Not the classic
property Age : integer read FAge write SetAge scheme)
Quite possible--but in my view that would still be a mistake; I regard
AttributeItems as an internal implementation detail that should not be
exposed. From my perspective, "property Age : integer" is the preferred form
of exposure regardless of whether Age is implemented internally as a field,
an attribute object, or a calculation. The relation between internal members
and public properties is not a 1::1 affair.
bobD
|
|
|
| Back to top |
|
|
Harley Pebley
Guest
|
| Posted: Thu Feb 05, 2004 10:01 pm Post subject: Re: Object attributes and notifications |
|
|
| Quote: | How do people here keep their business objects aware of changes to their
attributes? ... the class I use to implement ISubject contains a
reference counted list of Observers so making the business object an
observer of its attributes would mean that it would never be freed due to
cross referencing.
|
One route would be instead of having a list of IObserver have a list of
TNotifyEvent (or your own type as needed) to the appropriate IObservers. Of
course, the IObservers have to be sure to unregister themselves when they
go away or you'll end up with stale callback references.
HTH,
Harley Pebley
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
