Thanks in advance
Francisco

I ruled out performance as an important reason. It’s a reason, but not always an important one. I’m sure Federico will now want to reply that for many libraries, it is an important reason. He’s right and it’s very good that these libraries (for me they are the infrastructure layer) are being maintained with performance in mind. So, agreed .. it’s a reason.

My main reason is more obvious. With or without reason, these days a lot people are a little bit scared about the licensing and patenting issues that might or aren’t coupled with some of the popular modern development environments and programming languages. Yet a lot people want to use them. As long as we make sure that our most important libraries are written in a patent-free environment like GObject, we have not much to fear. For GObject there are very good language binding code generators that will generate a language binding for your popular modern programming language.

The other reason (it’s more or less the same reason, but a different point of view) is that you can develop core shareable components of your software in libraries that contain pure and well designed GObjects. You’ll have the ability to enjoy the power of a higher programming environment after creating bindings. The good news is that you can pick the, for your situation, most interesting higher programming language to develop on top of your library. Yet the big picture for all the softwares that will depend on your GObject libraries will be exactly the same. It won’t (really) matter which higher programming language will be used.

So why design patterns in GObject? Obviously because a) most design patterns are platform and language neutral, you can make the implementations platform and language neutral too. And b) because you’ll steer all your developers (no matter how low or how high their favorite programming language is nor which one they picked for the task) into developing the design pattern way. Yet not having to duplicate shareable implementation code. And of course c) because of the many benefits that come with practising design patterns while making design decisions (integration with unit testing and extreme programming, knowing the fact that you are using proven solutions for typical problems, decoupled classes which results in less interdependencies which results in more reusability, etcetera).

I have been working on my GObject skills, and have also been _attempting_ to implement examples from the Head First book. It is really cool to see it done from someone with some real experience.