Splitting up a utility DLL into smaller components in C++

Question

We have a core library in the form of a DLL that is used by more than one client application. It has gotten somewhat bloated and some applications need only a tiny fraction of the functionality that this DLL provides. So now we're looking at dividing this behemoth into smaller components.

My question is this: Can anyone recommend a path to take to divide this bloated DLL into a set of modules that have some interdepencies but do not necessarily require all other modules?

Here are the options as I see them but I'm hoping someone can offer other possibilities:

1. Create a "core" dll and several "satellite" dlls which use the core and possibly other satellite DLLs.
2. Subdivide the contents of the bloated DLL into static libraries that the main DLL uses (to maintain the same functionality) but apps that don't want to use the bloated version can assemble the static libraries they need into their own dll or into the app itself.

I was hesitant to mention this but I think it may be important to note that the app uses MFC.

Thanks for your thoughts.

Answer 1

Somewhat related to your question is this question, about splitting up a very large C module into smaller ones.

http://stackoverflow.com/questions/748503/how-do-you-introduce-unit-testing-into-a-large-legacy-c-c-codebase

It seems your question has to do with the larger question of breaking some large blob of code into a more modular system. The link above is definitely recommended reading.

Answer 2

Without having all the details it is a little hard to help but here is what I would do in your situation

• provide both static and dll versions of whate3ver you release - for MT and single threaded.
• try to glean from the disparate clients which items should be grouped together to provide reasonable segmentation - without having layers of dependencies.

having a "core" module sounds like a good idea - and make sure you don't have too many levels of dependencies - you might want to keep it simple.

You may find after the exercise that one big dll is actually reasonable.

Another consideration is that maintaining multiple DLLs and both static libs and DLLs will hugely increase the complexity of maintenance.

Are you going to be releasing them all at once every time, or are they going to be mix and match? Be careful here - and know that you could create testing issues

If no one is complaining about the size of the DLL then you might want to consider leaving it as is.