A question about implementing my own listener

[Bill White]

I am trying to implement my own listener model (for lack of better terms) that will help a manager type class determine if a record in a database has been updated.

What I am asking is, am I going down the right path? Does anyone here have any experience with something similar?


Here is what I have so far:

public interface ApprovalListener
{
public void approvalAlert(ApprovalEvent e);
}

public class ApprovalEvent extends EventObject
{

/**
* @param source
*/
public ApprovalEvent(Object source)
{
super(source);
// TODO Auto-generated constructor stub
}

}

public class ApprovalManager implements ApprovalListener
{

private Collection approvalListeners;

public ApprovalManager()
{
super();
// TODO Auto-generated constructor stub
}


public void approvalAlert(ApprovalEvent e)
{
// TODO Auto-generated method stub

}

public void addApprovalListener(ApprovalListener l)
{
if(approvalListeners == null)
{
approvalListeners = new ArrayList();
}

if(approvalListeners.contains(l))
{
return;
}

approvalListeners.add(l);
}

}

[Ko Wey]

This is not the way I make my own events

I use one interface and 3 classes

1/listener-interface
2/ event class
3/ class that implements the listener
4/ class that fires the event AND has the methods addListener removeListener

In your code, you have merged the last two classes in one:

ApprovalManager must listen to the event (implements listener) or fire the event( � la JButton...)

public class ApprovalManager implements ApprovalListener
{

private Collection approvalListeners;

public ApprovalManager()
{
super();
// TODO Auto-generated constructor stub
}


public void approvalAlert(ApprovalEvent e)
{
// TODO Auto-generated method stub

}

public void addApprovalListener(ApprovalListener l)
{
if(approvalListeners == null)
{
approvalListeners = new ArrayList();
}

if(approvalListeners.contains(l))
{
return;
}

approvalListeners.add(l);
}

}

[Ulf Dittmer]

For a no-frills solution you could go with implementing Observer on one side, and extending Observable on the other, thus saving you from having to create your own event class.

[Bill White]

For a no-frills solution you could go with implementing Observer on one side, and extending Observable on the other, thus saving you from having to create your own event class.

First, I thank the both of you for your replies. I really appreciate it.

Next, the observer pattern approach sounds very no-frills, and therefore the way to go!

Question on this though, is there any possible caveats w/ a class implementing Observer and extending Observable?

Here is what I would like...

DocApprovalManager implementing Observer
DocApprovalQueue implementing Observer extending Observable
DocApprovalItem extending Observable

DocApprovalManager observes DocApprovalQueue
DocApprovalQueue observes DocApprovalItem

When an item changes, it updates the Queue object, does what ever queue operations are neccessary, then updates the DocApprovalManager object which again performs any manager type operations that may be neccessary.

Does this sound like a reasonable approach?

Again, thank you.

[Ulf Dittmer]

Sounds like a workable approach if you need to make sure that first the Queue has access to the Item, and then the Manager. If Manager and Queue can operate independently, both could observe Item, thus simplifying the dependencies.

There's a tutorial on DeveloperWorks on event delivery techniques in Java.
[ November 17, 2005: Message edited by: Ulf Dittmer ]

[Bill White]

Ulf,

Thank you very much.
[ November 17, 2005: Message edited by: Bill White ]