Strategies for taking a program apart

Like Nish said, it should be a simple matter to move the code into static LIB files, and just link them in. If you're careful with your includes, you shouldn't even have too many issues.

Hopefully, you're starting with a fresh project and not modifying the one that already works. :)

The approach is to draw a layered diagram based on available dependencies -- a manual work, but it will direct you very well in structuring future development (for this project, but for new ones as well).
This served me well in many big projects.

With .NET I developed a simple utility: using Reflection to draw dependencies from executables is a snap. With C++ I saw some some restructuring utilities, but many years ago. Even manual work will help.

Would you look at my answer to similar question?

Here: Help on re-engineering a big project into DLL modules.[^].

Apparently, that my answer would hardly help OP because she or he was actually lost in linking technique (but the Question marked "solved"). Maybe you would be able use the idea and get job done?

This is kind of a refinement of SAKryukov’s answer, he’s, in my view, definitely heading in the right direction.

Depending on the size of the project - DoxyGen[^] together with Graphwiz[^] can help you get a detailed overview of the project with a graphical representation of the inheritance tree and other class interaction.

Doxygen can be set up to use Graphwiz to generate the various graphical representations based on the source code. DoxyGen can be set up to work with all of the code - even if it's a documentation tool, it can generate output for undocumented code, private variables, and so on.

This may help you decide how to organize the code into separate dll’s.

Depending on the size of the project, it’s also possible to use DoxyGen as a foundation for a tool that may partially automate the process – probably not a trivial task - it’s open source so you may modify it in any way you want.

Update for database layer
This is a great tool, easily modifiable to suit your needs, Database Helper v 2.0.0[^] - The tool also shows how to use SMO.

Regards
Espen Harlinn

The first thing to do is make sure that you don't loose any of the dependency isolation you've got with the EXE + big DLL. What I mean by that is don't allow anything to leak across the boundary between the two as you do your integration. Using unit tests can be a good way to make sure you don't make things worse.

Once you've done that make sure all the class declaration and definitions are in their own files and that any of the source files can compile on it's own without any fancy compiler settings or fiddling. This is really important as it's hard to look for ways for breaking dependencies when source files can be compiled standalone. It's also harder to write unit tests for them as well.

The next thing to do is to look to see where you can split the DLL into smaller chunks. Look for things you can wall off behind interfaces. Instead of passing concrete classes around refactor the code so it's passing references to an interface class instead.

As a rough and ready example say you've got two bits of code. Chunk A creates an object of class cA and passes it to chunk B. B uses some subset of it's functionality. You can introduce a new interface class, iA that does the bits B wants of cA and derive cA from it. Then refactor B to only use iA. What've you done is remove any dependency on cA from B and left a smaller dependency on IA.

After this phase hopefully you'll have something like a bunch of small clusters of classes which only talk to each other through abstract, interface classes.

Next start to look for things that you can bundle up into new classes or interfaces. API calls all over the shop is a sign that the code can do with this sort of attention. Instead of directly using libraries and APIs wall them off behind another interface and you'll see even more places you can separate the code into more manageable chunks.

Then you've got all the balls ache of actually abstracting out the clusters into their own libraries and linking them with the main EXE. That shouldn't be too hard though if you've factored them into nice little bundles with minimal dependencies on the others.

Cheers,

Ash

Hey guys,

So I started getting my hands wet after looking and playing around with the code a bit. I'm currently extracting the database layer, which should sit above the base class but below the controls and UI layers.

A difficulty is that the separation between the GUI and the business logic is not very clear-cut and sometimes classes are bundled together in the same file just for convenience. To separate those out would be one of my first tasks.

Another difficulty is that a lot of the dependencies trace back into a full circle, with components both above and below my layer.

I plan to create a bare minimum base class and derive the rest above my layer. Any suggestions on general rules of thumb on what I should bring down and what I shouldn't (ie. should I bring down as much as I could? as little as I could?)

Also, after refactoring and restructuring the project, I'm getting blocks and blocks of linking errors (mainly LNK2001 on the statics), how would I resolve them?

I guess this is more of an update/followup question than an answer, but I just want to make sure it reaches everyone who has helped me thus far and has been following the question.

Thanks!

The Project has taken on an interesting turn, and is now creating some new problems. (Please see here.)