Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Over the course of some months I've created a little framework for game development that I currently include in all of my projects.

The framework depends on SFML, LUA, JSONcpp, and other libraries. It deals with audio, graphics, networking, threading; it has some useful file system utilities and LUA wrapping capabilities. Also, it has many useful "random" utility methods, such as string parsing helpers and math utils.

Most of my projects use all of these features, but not all of them:

  • I have an automatic updater that only makes use of the file system and networking features
  • I have a game with no networking capabilities
  • I have a project that doesn't need JSONcpp
  • I have a project that only needs those string/math utils

This means that I have to include the SFML/LUA/JSON shared libraries in every project, even if they aren't used. The projects (uncompressed) have a minimum of 10MB in size this way, most of which is unused.

The alternative would be splitting the framework in many smaller libraries, which I think would be much more effective and elegant, but would also have the cost of having to maintain more DLL files and projects.

I would have to split my framework in a lot of smaller libraries:

  • Graphics
  • Threading
  • Networking
  • File system
  • Smaller utils
  • JSONcpp utils
  • LUA utils

Is this the best solution?

share|improve this question
Keep in mind that you should be able to build a directed graph of your dependencies. If some of your modules depend on modules which depend on them, you're just asking for trouble. If you can't structure this such that the dependencies aren't circular, you shouldn't mess with it. – Bobson Mar 18 '13 at 16:42
It's also depend on how your programming and related programming enviroment, manages libraries and related concepts such libraries, packages, namespace, and alike ... – umlcat Oct 27 '14 at 17:19
up vote 11 down vote accepted

I'd personally go for many small libraries.

  • Discourages developers from creating dependencies between otherwise unrelated packages.
  • Smaller more manageable libraries that are much more focused.
  • Easier to break up and have separate teams manage each library.
  • Once you have a new requirement that's sufficiently complex, its better to add a new module rather than find an existing library to shove the new code in. Small libraries encourage this pattern.
share|improve this answer
Overall I agree although I have seen cases where the small library approach wasn't well managed and got out of hand. On one project each library had semi-duplicated data access layer code. On another, there were too many dependent relationships between libraries. – jfrankcarr Mar 18 '13 at 18:04
@jfrankcarr True, poor code management can affect any project. My sense is that projects with monolithic libraries are more susceptible to than projects with small 'micro-libraries'. – p.s.w.g Mar 18 '13 at 18:43

You've given one side of the trade-off, but not the other one. Without a "fair and balanced" of the pressures you're operating under, we can't possibly tell you.

You say that splitting the libraries will make all your projects smaller. That's a clear plus. I can imagine various minuses:

  • splitting the libraries is in itself an effort, even if it has to be done only once.
  • maintaining versions of many libraries consistently is a small but persistent additional effort.
  • it is not as easy to be sure that every project does in fact really bundle the things it needs
  • splitting may not be possible as cleanly as you believe at the moment, and introduce extra work, maybe even threaten the conceptual integrity of some modules.

Depending on how probable/important such counterarguments are for you, splitting may or may not be the right choice for you. (Note that the dichotomy between "splitters" and "lumpers" is considered by many to be a fundamental personality trait that is not susceptible to logic in the first place!)

That said, the different tasks you say your modules are doing are so far removed from each other that I'd consider at least some splitting probably called for.

share|improve this answer

There isn't a clear cut answer. The best driving factor I can think of is how interrelated are the libraries now, and do you expect them to become related later. If you have a complex web of dependencies then one big library will probably be easier, if you have minimal relationships then you can split them up cleanly.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.