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 areHow 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.
Splitting up a single project into libraries
design;libraries
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.