Design patterns in GObject at FOSDEM

Somebody of the FOSDEM team asked me to do a talk about programming techniques a.k.a. design patterns using GObject.

I have to decide whether or not I’ll do it tomorrow. So I thought, well .. okay. Let’s prepare some samples.

Because else this blog entry would be to long, I created a page that explains the proxy and strategy design patterns and contains the links to the samples.

Note that yes, I did read Head First Design Patterns. And that yes, I based the strategy sample on the chapter in that book.

Also note that I’m planning to create an XSLT for generating GObject interfaces and classes using codegen. If you want to help me with that, contact me.

There’s probably not a single good reason why to do this type of development using GObject and not using a higher environment like C# or Java. My talk will not illustrate why you should use a programming language like C with glib-object.h rather than C# or Java. It’s not going to be the point. I guess there’s no real reason. In fact is any discussion about which programming languages is the better, stupid. The talk will be about what is possible. I’m not going to play the defender of the GObject religion.

6 thoughts on “Design patterns in GObject at FOSDEM”

  1. Pingback: Samokk is a Geek » GObject hell !

  2. Thank You!

    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.

  3. A GObject generator with XSLT sounds interesting. I could lend a hand, if only in irregular bursts of activity. I’ve written XSLT for a few automated tasks.
    I’ve also designed an experimental I/O framework over GObject called GOIO (https://gna.org/projects/goio), some interface-heavy stuff, so I’m quite into “this type of development”. Write if you need any help.

  4. Pingback: Phenomena in the days of Philip » Blog Archive » Some conclusions, more on codegen and GObject

  5. I found myself two reasonable good reasons why it’s important to be skilled in the tactics of design patterns when doing GObject libraries. And why, in general, do GObject libraries.

    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).

Comments are closed.