BorlandTalk.com

Ivo Bauer · Guest

Hi!

I've got an object that exposes a couple of events. As with many other
objects, not necessarily all events have the same prototypes. I'd like
to be able to make multiple objects observe the events of that object.
With the observer pattern, I can make multiple objects observe just
one event of the object which is being observed. Of course I could
create one separate observer for each event but this doesn't look good
to me. Is there a way how to customize/extend the observer pattern to
be able to register/unregister for observing multiple object events at
once?

Thanks in advance.

--
Ivo Bauer [OZM Research]

Joanna Carter [TeamB] · Guest

"Ivo Bauer" <abuer (AT) zom (DOT) zc> a écrit dans le message de news:
45a21bfa (AT) newsgroups (DOT) borland.com...

| I've got an object that exposes a couple of events. As with many other
| objects, not necessarily all events have the same prototypes. I'd like
| to be able to make multiple objects observe the events of that object.
| With the observer pattern, I can make multiple objects observe just
| one event of the object which is being observed. Of course I could
| create one separate observer for each event but this doesn't look good
| to me. Is there a way how to customize/extend the observer pattern to
| be able to register/unregister for observing multiple object events at
| once?

What I do is to use a concept which has been called Aspects, but it is also
known as a Parameter Object. In .NET, all events are multicast (a type of
the observer pattern) and the method prototypes for the event all derive
from the EventHandler delegate (method pointer) type. The base argument
object class and the delegate are declared like this :

public class EventArgs
{
public static readonly EventArgs Empty;

static MyArgs()
{
Empty = new EventArgs();
}

public EventArgs() : base() { }
}

public delegate void EventHandler(object sender, EventArgs args);

This the allows you to derive all your event argument objects from EventArgs
and pass them to the same pattern of event handler. So you get a Parameter
Object like this :

public enum SelectionType
{
Empty,
Single,
Multiple
}

public class SelectionChangedEventArgs : EventArgs
{
private SelectionType selectionType;

public SelectionChangedArgs(SelectionType selectionType) : base()
{
this.selectionType = selectionType;
}

public SelectionType SelectionType
{
get { return selectionType; }
}
}

Consequently, the Observer pattern needs to change slightly :

public interface ISubject
{
void Attach(IObserver observer);
void Detach(IObserver observer);
void Notify();
}

public interface IObserver
{
void Update(object sender, EventArgs args);
}

Then, if you want to, you can derive from IObserver to give you:

public interface ISelectionObserver : IObserver
{
void Update(object sender, SelectionChangedEventArgs args);
}

And your observing class class can implement multiple I...Observer
interfaces, or each of several observing classes can implement one
interface.

Finally, your subject class can choose which observers to broadcast to by
checking for the derived IObserver interface type and only sending messages
to that/those observer(s).

I'm sorry it's in C#, I find it easier to think in that language at the
moment, but does that help ?

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

Joanna Carter [TeamB] · Guest

"Joanna Carter [TeamB]" <joanna (AT) not (DOT) for.spam> a écrit dans le message de
news: 45a22552$1 (AT) newsgroups (DOT) borland.com...

Oops ! Errata...

| public class EventArgs
| {
| public static readonly EventArgs Empty;
|
***** static EventArgs() static constructor
| {
| Empty = new EventArgs();
| }
|
| public EventArgs() : base() { } // default instance constructor
| }

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

Joao Morais · Guest

Ivo Bauer wrote:

Ivo Bauer · Guest

Hi, Joanna!

Joanna Carter [TeamB] napsal(a):

Ivo Bauer · Guest

Joao Morais napsal(a):

Joao Morais · Guest

Ivo Bauer wrote:

Peter Morris [Droopy eyes · Guest

Bold does it something like this

Subject.Subscribe(SomeEnumValue);

Observer.Receive(SomeEnumValue);

That way the subject can have a kind of hash table holding a list of
observers that are interested in each enum. When something subscribable
happens you retrieve the observer list based on the correct enum and then
notify each one.

--
--
Pete

Blessed are the geek, for they shall public class GeekEarth : Earth {}
====
Audio compression components, DIB graphics controls, ECO extensions,
FastStrings
http://www.droopyeyes.com
http://mrpmorris.blogspot.com
====

Ivo Bauer · Guest

Peter Morris [Droopy eyes software] napsal(a):

Ivo Bauer · Guest

Joao Morais napsal(a):

Peter Morris [Droopy eyes · Guest

Hi

Ivo Bauer · Guest

Hi, Peter!

Thanks for your insights. Please find my comments inlined below:

Peter Morris [Droopy eyes software] napsal(a):

Graeme Geldenhuys · Guest

I'm using the tiOPF framework and was having the same problem and found
a solution in this past week. I'm trying out an idea based on the Java
Event Listeners design and so far it is working very nicely. This
allows me to register for specific events and not just a
one-size-fits-all as tiOPF currently has (and most Observer
implementations). It can be so fine grained to the point where I can get
notified when a property changes (even if I don't use attribute types).

And all that using a single internal observer list - no need for
multiple observer lists.

I implemented the Observer pattern based on Interfaces. Note that tiOPF
doesn't use Interfaces in it's design and I am very new to Interfaces,
but this solution seemed to lend itself to Interfaces very well. So far
so good. Wink

The Observed Object doesn't need to know anything more
about the observing objects, other than that they implement a specific
interface.

I created a TCustomBusinessObject and TCustomBusinessObjectList that
descend from the standard tiOPF base classes and has the following extra
methods. I had to introduce IInterface into my object hierarchy myself
due to tiOPF not using Interfaces - as I mentioned before.

TCustomBusinessObject
....
procedure AddListener(Listener: ITIObjectListener); virtual;
procedure RemoveListener(Listener: ITIObjectListener); virtual;
end;

TCustomBusinessObjectList
....
procedure AddListener(Listener: ITIObjectListListener); virtual;
procedure RemoveListener(Listener: ITIObjectListListener); virtual;
end;

Both classes contain a single TEventListenerList object defined as follows:

{ all new event listeners will descend from this interface }
IEventListener = interface(IInterface)
['{7461C599-974C-4592-8173-A3550BB267D9}']
end;

TEventListenerList = class(TInterfacedObject, IEventListenerList)
private
FListeners: IInterfaceList;
public
{ IEventListenerList }
function Add(Item: IEventListener): Integer;
procedure Clear;
procedure Delete(Index: Integer);
procedure EnumListeners(EnumListenerProc: TEnumListenerProc);
function GetCount: Integer;
function GetItems(Index: Integer): IEventListener;
procedure Remove(Item: IEventListener);
constructor Create;
end;

Now lets use a simple example by looking at the TtiObjectList and how I
extended it. Currently I can observe the ObjectList and get notified if
something changes and the changed ObjectList gets passed to the
Observers in the Update method. This is the problem. What actually
changed? Was something added or deleted for example? The current
implementation didn't give us any such hints!

To solve this I then created the following Interface which can be used
to get notified when items get added or deleted from the ObjectList.

ITIObjectListListener = interface(IEventListener)
['{3002F5D7-0504-4AB9-B993-FD1E272BF64A}']
procedure ItemAdded(AObject: TTiObject);
procedure ItemDeleted(AObject: TTiObject);
end;

I then override the relevant methods like Add, Delete, etc to fire off
the notifications. Here is an example for handling the adding of a object.

procedure TCustomBusinessObjectList.Add(const AObject: TtiObject);
begin
inherited Add(AObject);
FLastItemAdded := AObject;
FListeners.EnumListeners(@EnumDoAdd);
FLastItemAdded := nil;
end;

procedure TCustomBusinessObjectList.EnumDoAdd(Listener: IEventListener);
var
lTIObjectListListener: ITIObjectListListener;
begin
if Supports(Listener, IID_TIObjectListListener,
lTIObjectListListener) then
lTIObjectListListener.ItemAdded(FLastItemAdded);
end;

The benefits of doing things this way is that your connections between
objects are explicit and you only implement what you need in observer
objects. The downside is that it doesn't lend itself to a generic, "tell
me when property X of object Y changes" - though I believe that over
time I would see common patterns occurring that could be refactored
either into helper classes or into the base classes themselves.

Regards,
- Graeme -

Ivo Bauer wrote:

Peter Morris [Droopy eyes · Guest

Well I didn't read it all so I might be wrong, but this is my impression
from your text (not source).

If an observer asks to be notified about something then it should only be
notified when that specific thing happens. I get the impression that some
code in your observer will be executed for *anything* that happens, ather
than only what it is interested in. I think this is more code, and when you
have lots of subscribers it will really slow down your app if you have to
send out lots of notifications.

--
--
Pete

Blessed are the geek, for they shall public class GeekEarth : Earth {}
====
Audio compression components, DIB graphics controls, ECO extensions,
FastStrings
http://www.droopyeyes.com
http://mrpmorris.blogspot.com
====

Ivo Bauer · Guest

Ivo Bauer napsal(a):