Re: Review of gnio, round 1

[Philip Van Hoof <spam pvanhoof be>]

On Mon, 2009-04-27 at 22:16 +0200, Alexander Larsson wrote:
> On Mon, 2009-04-27 at 11:39 -0400, Ryan Lortie wrote:

> > Going forward from this point, you argue that there should be a massive 
> > reduction in the number of classes.  I think that your decision-making 
> > here is influenced by the fact that we're working in C.  I tried to 
> > think out a logical class structure that I would do as if I had a 
> > language like Vala to do the dirty work for me -- that is, I favoured 
> > subclassing where it makes sense for conceptual clarity rather than in 
> > order to avoid an explosion of classes.
> 
> That is not quite correct. I don't mind having classes if it e.g. means
> more typing for the implementation. In fact, this is pretty obvious if
> you look at gio itself which is pretty well factored wrt classes and
> interfaces. However, what I think is bad about the many classes is that
> they increase the complexity (or at least the percieved complexity) of
> the API. There is a lot more classes to understand when e.g. reading the
> docs, and its a lot harder to keep the class hierarchies and
> dependencies in your head. This is especially bad when many classes
> don't add any advantages to the user. 
> 
> Its also a problem because it means its a pain in the ass to extend the
> API. For instance, with the minor change i'm about to do in the socket
> construction case we will already support SCTP sockets. However, we need
> a full suite of useless subclasses in order for it to match the tcp
> case.

When in a design you use classes a lot you try to single out
functionality into classes; you delegate solving the problems.

The aim being that the API of the one delegating becomes sealed once all
tests, unit and API-usability, for its own function(s) succeed.

When developing this way changing behaviour means developing a new
class, or subclassing another. It rarely means adapting an existing
sealed class. And if you do, the requirement is that all its test must
again succeed. Again both the unit tests and the API-usability tests.

So when you say:

> its a pain in the ass to extend the API.

... then that frightens me:

Extending the API should mean making a new class. Rarely should it mean
adapting an existing sealed one.

It's supposed to be a pain in the ass to extend API by reopening sealed
stuff. You're supposed to extend by adding components on top. You're
supposed to design in such a way that this becomes possible (delegation
and composition over inheritance).

In my opinion, especially in the GNOME platform, should the majority of
classes have been slit out into many smaller ones.


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be