[haiku-appserver] Re: [openbeos] Launching the input_server from the app_server...

  • From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 28 Dec 2006 19:45:01 +0100

On 2006-12-27 at 20:14:56 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On 2006-12-22 at 11:30:10 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> > > wrote:
> > > It's a common design pattern that an object knows its owner, and
> > > sends
> > > it a message on some special occurence.
> > Yeah, it's one aspect of the the "lazy developer" pattern, since one
> > could
> > avoid this kind of dependency by introducing a listener/observer
> > mechanism.
> > ;-)
> ;-)
> But seriously, that is the same thing (just that there is only one
> observer, but you don't know anything about it either beyond notifying
> it).

It's a circular dependency after all. If you introduce something like this 
at each level of your class hierarchy, your bottommost class will depend on 
the topmost one and you won't, for instance, be able to reuse it 

A cycle like this:

     A <---.
     |     |
owns |     | notifies
     |     |
     V     |
     B ----.

can be broken up easily by introducing a B-Observer class that is 
implemented by A (one wouldn't even support multiple observers, if not 

Anyway, I just wanted to throw in that "child knowing parent" is not really 
a design pattern and one should not apply that carelessly. It certainly 
doesn't harm in a closed subcomponent/package/API, though.

Oh, and regarding garbage collection, modern implementations (actually even 
less modern ones ;-) don't have a problem with circular object references 
(even if you avoid circularity at class level, you'll always have it at 
object level). You just need to make sure you severe the references that 
point to no longer active objects (e.g. don't forget to remove listeners or 
use weak references for listeners).

CU, Ingo

Other related posts: