Often I heard listener class
In general, a Listener is an object that specifically exists because it wants to know when something happens. For instance, you might want to have your bank software send a customer a nasty letter if/when his account balance becomes negative. So you make a listener with the action of "send a nasty letter", and attach it to the account object in such a way that it will be invoked when the account balance becomes negatives. This allows a designer to separate the action taken in a particular condition, from the condition itself.
Author
Quote:Original post by Sneftel
In general, a Listener is an object that specifically exists because it wants to know when something happens. For instance, you might want to have your bank software send a customer a nasty letter if/when his account balance becomes negative. So you make a listener with the action of "send a nasty letter", and attach it to the account object in such a way that it will be invoked when the account balance becomes negatives. This allows a designer to separate the action taken in a particular condition, from the condition itself.
Could you give me a simple code to show it?
I think it maybe like this:
if(account balance becomes negatives){send a nasty letter();}
it seem the listener is not used.
// Interfaceinterface AccountNegativeListener{ void onAccountNegative();}// A single listenerclass SendNastyletterListener extends AccountNegativeListener{ void onAccountNegative() { // send a nasty letter here }}// Source of eventBankAccount{ AccountNegativeListener negListener; public withdrawMoney() { // some stuff // .. // Fire event to listener if appropriate if (isBalanceNegative()) negListener.onAccountNegative(); }}Usually the implementation lets you attach as many listeners as you want, but thats a simple extention once you've got the basics working.
Alright, let's start with your code there. Here's the problem: that code's probably in the "Account" class. It isn't in the "Customer Relations" class. It's not the appropriate class to be sending out letters. What if the "Customer Relations" class has all the letters, and is the only class that controls the letter printer? Also, suppose different guys are maintaining the two classes. Why would the guy maintaining the Account class have to also maintain the text of the nasty letter?
How about instead, we do this in the Account class:
if(account balance becomes negatives){do whatever we do when account balance becomes negative();}
The obvious problem, there, is that it doesn't tell us WHAT we do when the account balance becomes negatives. Listeners are more like this:
if(account balance becomes negatives){tell whoever cares that the account balance became negative()}
Now, sometime before the account balance has become negative, the Customer Relations object tells the Account, "Hey, I care when the account balance becomes negative!" It does this by registering its listener with the account class. When the balance becomes negative, the Account class invokes that listener.
How about instead, we do this in the Account class:
if(account balance becomes negatives){do whatever we do when account balance becomes negative();}
The obvious problem, there, is that it doesn't tell us WHAT we do when the account balance becomes negatives. Listeners are more like this:
if(account balance becomes negatives){tell whoever cares that the account balance became negative()}
Now, sometime before the account balance has become negative, the Customer Relations object tells the Account, "Hey, I care when the account balance becomes negative!" It does this by registering its listener with the account class. When the balance becomes negative, the Account class invokes that listener.
Author
Quote:Original post by Sneftel
Alright, let's start with your code there. Here's the problem: that code's probably in the "Account" class. It isn't in the "Customer Relations" class. It's not the appropriate class to be sending out letters. What if the "Customer Relations" class has all the letters, and is the only class that controls the letter printer? Also, suppose different guys are maintaining the two classes. Why would the guy maintaining the Account class have to also maintain the text of the nasty letter?
How about instead, we do this in the Account class:
if(account balance becomes negatives){do whatever we do when account balance becomes negative();}
The obvious problem, there, is that it doesn't tell us WHAT we do when the account balance becomes negatives. Listeners are more like this:
if(account balance becomes negatives){tell whoever cares that the account balance became negative()}
Now, sometime before the account balance has become negative, the Customer Relations object tells the Account, "Hey, I care when the account balance becomes negative!" It does this by registering its listener with the account class. When the balance becomes negative, the Account class invokes that listener.
thank OrangyTang and Sneftel.
but how to register the Customer Relations class.
the sample OrangyTang give just call it directly.
Or the register is not important. It is important to put process function as a new class "Customer Relations Listener"
and this way,different guys could maintain it seperately .
Right?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
