Object-oriented design best practices

Here is another book review, this time about object-oriented design.

Programming Best Practices

We can learn by our own experience, we can use our common sense, we can learn by more experienced developers when contributing to an existing project. But to speed things up, reading a good old book is also a good idea.

For programming in general, not specifically for object-oriented design, see the blog post About code quality and maintainability.

Object-Oriented Design Heuristics

For OO design, the well-known Design Patterns book is often advised. But most of the design patterns are not often applied, or are useful only for big applications and frameworks. How often do you create an Abstract Factory or a Facade?

On the other hand, the book Object-Oriented Design Heuristics, by Arthur Riel, discusses in details more than 60 guidelines − or heuristics − that can be applied to all projects, even for a small codebase with three classes.

Example of an heuristic:
Keep related data and behavior in one place.

If a getter method is present in a class, why is the data used outside the class? The behavior implemented outside the class can maybe be implemented directly in the class, so the getter can be replaced by a higher-level method.

Other example:
Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly.

By following this heuristic, god classes should be avoided. An example of a class that can be split in two is where some methods use only attributes A and B, while some other methods use only attributes C and D. In other words, if a class has non-communicating behavior, that is, methods that operate on a proper subset of the data members of the class, then the class can be split.

All the heuristics can not be followed all the time. That’s why they are called “heuristics”. But when an heuristic is violated, there should be good reasons behind that decision, and the developer should know what he or she is doing.

Event-driven programming

One missing concept in the book is event-driven programming.

With GObject, we are lucky to have a powerful signal system. It is a great way to decouple classes. When an object sends a signal, the class doesn’t know who receive it.


Programming best practices are useful to maintain a good code quality. Object-Oriented Design Heuristics will give you the knowledge to better write object-oriented code, either for small projects, big projects or API design in a library.

Switch from CMake to Autotools

Last week I’ve migrated the build system of LaTeXila from CMake to the Autotools. Here are the reasons.

The GNU Coding Standards

With CMake, some important make’s targets are missing, for example make uninstall. The main problem is that CMake doesn’t follow the GNU Coding Standards (GCS). The purposes of the GCS, with regard to a build system, is to make a program portable, easy to install, and consistent with the way other softwares are built and installed.

The GCS has several decades of experience, the standards are well established, and we can trust the GNU hackers for having well conceived them. Those that don’t follow them are devoted to reinvent the wheel: they will be faced sooner or later by the same problems already solved by the GCS and the Autotools…

Following standards is important both for users and packagers. If every software uses a different build system, with different options etc, it is a nightmare.

Available macros for GNOME applications

Another reason to use the Autotools, for a GNOME application, is to use the available macros: for the translations (intltool, ITS Tool), the documentation (yelp), the settings (gsettings), …

Creating a tarball

With the Autotools it is as simple as running make distcheck, and putting some files in EXTRA_DIST or prefixing Automake variables with the dist modifier.

It is more complicated with CMake. CPack can be used, but it is far from automatic. When reading the CPack documentation, I changed my mind and wrote a shell script instead.

Learning the Autotools

The Autotools are not as Autopain as people generally say. The learning curve is maybe steeper, but with a good book, there is no reasons to be afraid.

That said, there are certainly problems in LaTeXila, so some tests before the stable release would be more than welcome 😉

About code quality and maintainability

It can be difficult to write clean code, that is easy to understand, split in nice and well-defined functions that do one thing but do it well, with good variables names, and so on. For the maintainability, it is really important.

In fact, a code is read far more often than it is written. For fixing a bug, adding a feature, or simply see how it is implemented.

General Advices

There are some general advices, for example:

  • A function’s name should be sufficient to know all what the function really does.
  • Hide implementation details, and use the domain-specific vocabulary, no technical words, if possible. An extreme example: get_last_document() is better than get_top_stack().
  • Avoid focusing on performance from the beginning. About 10% of the code is responsible of 90% of the execution time. An optimized code is more difficult to understand, so it is better to optimize only the 10%.

Every Details Matters

Small details can also improve the code readability. Take for example this line:

g_return_if_fail (foo >= min_value && foo <= max_value);

And compare it with this one:

g_return_if_fail (min_value <= foo && foo <= max_value);

Which one do you prefer? In the second sample, we can visually see the foo variable between the minimum and maximum values.

Many such small improvements, taken together, make the code more enjoyable to read.

Code Complete

We can learn these and other advices by reading some (good) existent code, by working with more experienced developers, AND by sitting in a comfortable sofa with a cup of coffee or tea while reading a book.

I personally have read Code Complete last year. It seems the reference on the subject. But there are other similar books, for instance The Pragmatic Programmer.

Although the editor of Code Complete is Microsoft Press, the book is not related to Microsoft or Windows. The author explains sometimes stuff related to open source, UNIX and Linux, but one can regret the total absence of the mention “free software” and all the benefits of freedom: be able to learn by reading other’s code, etc. But if you are here, you already know all of this, because you are on the good side 😉