The Risk Of Common Libraries

By | February 26, 2007

When you work on multiple projects you will come to one simple problem. Multiple projects use the same source code, or base classes! An easy example is a log library that aids in logging all problems, function calls, etc in an application. This is something you’re likely to use in all projects. So it would be perfect for an external library, be it a jar (in Java) or a dll in Windows.

So creating libraries with common objects in it seems to be a perfect way to balance duplication of code and ease of maintenance.  But there are some things to take in mind when developing common libraries:

  • Changing the library could potentially cause a lot of applications to crash or stop working
  • When multiple people are working on the library it is possible it becomes fat and bloated

No need to explain the first, that’s easy! But the second one is a bit less obvious. If you have a lot of classes in the library it means the library becomes bigger. In a worst case scenario the applications will use about half of the libraries classes. When applications use less then 70% of the classes in a library it’s probably a bloated one.
Fat is bad!
Why is that so bad. Well lets consider a real-time system. If a car starts there is a lot of software running to check temperature, speed and other controls of the car. Lets imagine that the speed library has gotten a bit bloated. This would mean it takes longer to update speed information and the fat would take precious time from the rest of the application.

This could cause incorrect information to the driver or the cruise control. Can you envision the problems it could create. So maybe it’s time to rewrite the library a bit!

Leave a Reply