[haiku-appserver] Re: invalidation again
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Fri, 15 Apr 2005 15:35:56 +0200 CEST
> > Yeah, I tried to follow that. The main problem was all these
> > clipping
> > regions with completely obscure names. They give no hint what they
> > are
> > used for.
>
> Well, maybe you're right.
>
> fVisible - is the actual visible region of a layer
> fFullVisible - is the visible region of a layer + all the visible
> regions
> of all layers that it contains (the whole tree).
> fFull - is the region equal to layer's bounds + client specified
> clipping
> regions BView::ConstrainClippingRegion(). (this how the Layer's
> visible region would look like if it would be completely visible
> and have no children)
>
> fVisible + fFullVisible == fFull if the Layer is entirely visible.
Ok, so what is RootLayer::fUpdateReg (for example)?
I must say I don't like the design with the "current layer". I think
that the layers and the data they carry is munched together with the
managing of multiple layers. This is the confusing part. So inside an
instance of layer, there is code concerning that layer (instance), and
then there seems to be code as if Layer was a static class. You set
some member variable of one layer instance, to manage another layer. So
it is completely confusing, which layer we're actually updating or
changing. You don't see this from the code, it just "happens" to work
if the client code knows what it is doing. This is not necessarily good
code, the correct usage should be enforced by the design, this would
make it all much more usable. And I think most of the bugs come from
client code not actually doing all the necessary things in order for
the mess in Layer to "magically" work correctly.
Ok, I don't like to "preach" or anything, so please don't take the
following that way. Take it as someone stating his experience, you may
agree or not agree. So here it goes:
In my experience, this is a good aproach to object oriented
programming: Usually, a class contains data and functions to manipulate
that data. Most of the times, there are multiple bits of data, which
depend on each other in some way. Certain combinations of the data
values can be considered "valid", other as "invalid". Now, the trick is
to enforce the "valid" combinations of data inside the class. So that
client code which uses the public methods of a class *can not* bring
the object into an "invalid" state.
As soon as you design your code so that you depend on the client code
to keep the data valid, you have a number of problems:
* You open up a lot of possibilities for bugs
* You make the code hard to understand, because you don't know
which part of the client code might mess with something and cause an
invalid state, you cannot enforce "code paths".
I know, you have all this "but it needs to be fast" stuff in mind. And
you think that "if I know what I'm doing, everything will be fine".
There might be occasions where it makes sense to have a framework of
classes manipulating each other and acting like "one" object. But I
think the current app_server design is completely overdoing this, for
_no_ good reason. I think a lot of the problems can be contributed to
this fact. So while you work on something, please try to make the extra
effort to refactor things. It will save so much time in the end.
Best regards,
-Stephan
Other related posts:
