[fpc-devel] Recent added support for Observer pattern in FCL

michael.vancanneyt at wisa.be michael.vancanneyt at wisa.be
Tue Aug 28 17:46:12 CEST 2012

On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote:

> Em 28/8/2012 09:15, michael.vancanneyt at wisa.be escreveu:
>> On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote:
>>> Why not let TFPObservedOperation as integer and define constants.
>>> It could define a constant like ooUser = 32
>>> Below ooUser is reserved for future default constants
>>> Above ooUser could be added custom messages
>>> This is how LCL messages works
>> Exactly because it is not meant as a general messaging interface, and I 
>> want the interface to reflect this.
>> There is a clear intended use case: Mainly notification of changes.
> This is the purpose i intend to use (replace my implementation). Basically is 
> a tree structure that needs to be observed. To avoid performance problems 
> like having to parse all the tree when a change occurs i defined actions when 
> a Child is added, deleted or inserted.

Exactly. You should use ooAddItem, ooDeleteItem, and pass the treenode in Data.

> To be clear what i would need to do with the current approach:

Your example is not correct. I don't see why you would not use ooItemAdded.

You observe a tree. Your observer code knows what it means if the tree sends 
a ooItemAdd or ooItemDelete. There is not even the need for a custom type here.

Do not forget that the implementor of some control decides (and documents)
what notifications he/she will send. The 4 standard ones will probably cover
everything. The observers need to know what they observe, and know what to
do for each operation.

If you make the operation an integer, an observer will never know if it has
covered all operations. With an enumerated type, the observer can implement the 5
enumerated values, and know that all operations have been covered.

We can agree on the exact number of operations that we define, but I will
not implement a system with an open number of operations.

If you think that each and every possibly imaginable operation needs its own
type of message, then you are IMHO on the wrong track. My original implementation 
didn't even have ooCustom, and I could observe all controls in the LCL with just 
the 4 messages ooChange,ooFree,ooItemAdd and ooItemDelete; That included
observing a tree.

Today or tomorrow I will commit the fpObserver unit, which contains a
basic mediator factory which I used to implement just that.


More information about the fpc-devel mailing list