Splitting up a single project into libraries

Question

I am working on a project/application that I feel is not very well organized, and parts of it intertwine in different ways. Everything works, but I can see things are not very modular.

Is it reasonable to split up an application into various libraries, even if they might not be reused by another application?

Just the mere thought of splitting it up into libraries reveals many problems with the current system. I feel it will encourage better design, and future reuse (There are talks of a new project that seems it could benefit from at least some of these libraries).

My concerns are

• How will it affect perfomance?
• How far should I go in splitting things up?
• If three libraries all depend on each other, is there a point in making them libraries? (perhaps it suggests a re-architecture of the modules)

My question seems to go against the wisdom of this answer, in that Dynamic libraries should never be created for a single app. Then the question becomes- how to ensure modularity in a large application?

Thanks!

EDIT: It seems I have used the term "shared library" too much, so I removed it to imply any kind of library (either static or dynamic). The essence of the question is whether to split stuff up into any type of libraries.

Answer 1

hmmm...

There are really two concepts at play here ...

There is Dynamic Library vs Static Library, which is what the question you refereed to was mostly dealing with. In this case what Neil here says and what the answer you referred to concluded is that on most implementations that use dynamic libraries the extra overhead is just not worth the trouble. Making libraries dynamically loadable by your application often times require some extra considerations regarding your code and how you deploy your application, that, unless you really need the feature, would often times make your app more complex rather than less.

Now, it is true that dynamic libraries are troublesome and should be used sparingly does not mean you should refrain from making libraries... quite the contrary, to split your code base in multiple quasi independent modules is just good practice, it will make your system overall easier to test and maintain.

Note that on some platform the concepts of dynamic and static libraries are quite dependent on the platform and language you are using. For example in Java, all libraries are on equal footings. I guess it would be somewhat in between dynamic and static where it is possible to change libraries without having to recompile what uses them but managing dynamically loadable and unloadable modules does require extra work to be done properly for anything more than the simplest use cases.

In most environments I have seen either it naturally supports dynamic libraries or if you wish to have dynamic libraries you need to specify this explicitly.

So in short YES do modularize your systems and do try to reduce interdependencies amongst your library, for example there should be no cycles when you create a graph on how your modules interconnect. (A->B->C->A) If such things occur then your separation is not quite right, if it just seems impossible to get rid of a cycle well perhaps thy were not meant to be separated in the first place, or perhaps your object modelization of your problem is deficient.

Note however that modularization does not eliminate the complexity completely, some of it is transferred to managing the interdependences, versions etc.

Hope this helps.

Answer 2

I would ask "why shared libraries?" Statically linked libraries are much easier to work with. If you don't need the "pluggable" features of dynamic loading of functions, then I would always go for static libraries. As for your particular situation, I don't think you have provided enough information for us to advise you on.

Answer 3

http://www.objectmentor.com/resources/articles/granularity.pdf

In my opinion, yes, you should be modularizing your code whether or not you'll reuse it for something else. You should be doing so because it is the one of the few things you can do that better prepares you for the future, whatever that is going to look like. While you can try to overdesign to make sure your code can respond to any change, you will invariably miss something. Modular code lets you pull pieces out that simply don't match what you're trying to accomplish anymore.

Making sure to work in discrete modules also lessens the opportunity for and thus invasion of unexpected/unwanted coupling. Having to be able to compile a module by itself really points out the dependencies it has and limiting those improves design so that applying changes to one area doesn't magically affect some remote part of the program....reduces that kind of thing anyway.

It also improves compile times. If you only build what you need to, and you're working with libraries and only changed one or two of them...then that's all you have to compile.

Answer 4

I've found that adherence to Unit Testing and TDD is a better way to enforce proper modularity without over-designing features that may never be used (e.g. creating libraries that never get reused). To do Unit Testing well, you'll need cleanly defined interfaces and small, single purpose classes. Pretty much the same thing you do for a well defined library.