I have a dilemma and wish to consult the wisdom of the collective.

;)

I am working on a rewrite of a large project.  As part of the process,
I am embracing the Object Oriented paradigm to its fullest.  I am, at
times, overwhelmed.  This may be one of those times.

I have been wrestling with the concept of creating objects that will
serve as attributes for the objects in the problem domain and have
decided that it is worth the effort for at least some of the pieces of
data.  

In particular, I have data items that represent prices of commodities.
These prices are quoted in differing precisions based on the commodity
in question.  This is compounded by the possibility that the same
commodity may be represented in different units based on the context
of the discussion.  So, I had the bright idea to encapsulate the
functionality of a TAttributePrice and use it as a data field in my
other objects.  This object will be able to accept a string (from an
edit) and convert it into a price as well as produce a string from the
price in varying formats.  I have created the attribute object.  It is
an observable class.  So far so good.

I have an object (TGraphImage) that contains several prices that
denote boundaries on a graph (FXLow, FXHigh, FYLow, and FYHigh).
TGraphImage also contains a boolean field FAutoScale that can be set
to true (and thus automatically sets the aforementioned values).
Conversely, if any of the 4 boundary fields are set manually,
FAutoScale should be set to off.

I had the properties XLow, XHigh, YLow, and YHigh using the
traditional Set..... procedures to check for an actual change in the
value and adjust FAutoScale when needed.

My intent was to publish the properties as TAttributePrice objects and
allow usage such as XLow.Value and XLow.AsString.  However, then I do
not have a good way to automatically set FAutoScale when the value
actually changes.

Do I expose every needed property of the attribute object and have
Set.... procedures to adjust FAutoScale?

Do I enlarge my Attribute objects to the point that they can report to
observers exactly which field they represent?

Do I give up on encapsulating the parsing and display functions of the
data?

Have I missed something obvious?

Now that I am converting these fields to attribute objects, I cannot
see a clean way to accomplish my needsand am afraid I am missing
something.  Elegance is not always achievable, but many times I have
given up and used brute force only to find that there *was* an elegant
solution that ended up being better all the way around.

If you don't have time for a dissertation, a point in a direction will
be appreciated.

Thanks

Dean

I too have struggled with the various notification strategies.  What I
have settled on is that things external to the "model" observe the
attribute (passive) while the object that contains them has a more
active role.

As such the GUI and other models subscribe as observes to the attribute.
 Attributes are written such that they will notify the owner when they
change (done via an owner reference).  With this I can have the owner
veto changes as well as noting them.  This solves the problem of have a
bazillion observers and allows the owner priority when changes are made.

eg:

procedure TAttribute.Changed;
begin
   FChanged := True;
   if FOwner <> nil then
      FOwner.AttributeChanged(self);
end;

procedure TOwner.AttributeChanged(Attribute : TAttribute);
begin
   if Attribute = FXLow then
      FAutoScale := False;
end;  

If this helps great; if not clear enough please respond.

Ken Revak