How do you structure your reusable libraries?

Question

How do you organize your code so that it can easily be ported across business projects without carrying unnecessary bloat?

For example (in .Net), let's say you have the following namespaces:

namespace Computers
    - Hardware
         - Motherboard
         - GPU
namespace Monitors
    - Display
         - Mirrors
namespace Peripherals
    - USB
    - PS/2

• Do you create a project per parent namespace and then reference that project dll in other projects?
• Do you create one big class library and port that thing around (even if you only need 5% of the library)?
• Or, do you just create one file and copy the code you need into that file; toting that file around into all the projects that you need to achieve a "plug and play" architecture (as bad as this seems)?

Edit: I'm not looking for .Net answers specifically, but it's the concrete example that I'm using (since an abstract example would make it harder to understand the question in this instance)

Answer 1

I keep each component as a discrete module, and use Maven to manage my dependencies (it's not just for Java, see this question, Byldan is a .Net equivalent).

That way you can reuse the code without having to include it in the project. In your example above I might have three artifacts, one for each namespace unless there's a good reason to keep them together (this helps enforce loose coupling).

Answer 2

I've found recently that I try to keep the number of projects down, if only so that the number of actual assemblies created in the end is reduced - I just find it easier to deal with during development. This is possibly because I find it difficult to create projects that are truly modular and independent of each other though.

I guess the general rule might be: if the project can really be developed independently of all others and plugged in to other projects without any other dependencies, then make it its own project. If you find that there are always other projects that need to be referenced in order for it to work (for example, perhaps in your Monitors project you find that nothing at all will work unless you also include the Computers namespace with the GPU classes), then I'd put them together in one project.

Apart from that, I don't think the rules are too hard and fast. Really depends on a lot on what's in the assemblies, it's hard to make arbitrary rules...

Just my two cents, not worth a lot...

Answer 3

Do you create a project per parent namespace and then reference that project dll in other projects?

Not necessarily. It usually ends up that way because my libraries typically aren't very big but you'll notice Microsoft certainly doesn't do that. System.Web exists even if you don't include the System.Web reference. You just get more classes if you do. Indicating that the System.Web namespace is used in several different DLLs.

Do you create one big class library and port that thing around (even if you only need 5% of the library)?

Yes. Hard drive space is cheap, cheaper than maintaining redundant code.

Or, do you just create one file and copy the code you need into that file; toting that file around into all the projects that you need to achieve a "plug and play" architecture (as bad as this seems)?

It depends on the function. I'd usually place something like this in a snippet. For example a typical function that shows up in my web projects is something like:

void ShowErrorMessage(HtmlTableRow row, string message)
{
   row.Cells.Clear();
   row.Cells.Add(new HtmlTableCell());
   row.Cells[0].InnerHtml = message;
   row.Cells.Attributes.Add("class", "error");
   row.Visible = true;
}

It's never seemed like a good candidate for a library function because then I'd have to pass in the CSS class I wanted to use and occasionally the colspan value for the cell. But you'll see some sort of implementation like this sitting in a few places in my web projects.

Answer 4

I take my cue from DNA, and copy all or parts of my one huge class library from project to project, even if I only use 1% of the library in any one project. I freely rewrite methods and classes as needed.

Although this approach is somewhat counter to conventional programming wisdom, I wouldn't knock it: it has worked very successfully for living things for the last 3.5 billion years. As in life, the alternative (cementing the interfaces and the implementations by sharing compiled assemblies across projects) inhibits change and virtually guarantees eventual extinction.

Answer 5

I start off with a single dll, and as it gets larger and begins to contain some fairly independent components, I may choose to factor them out as separate dll's. For me, it's primarily an issue of aesthetics - I like to keep things independent and orthogonal and well-organized. There is nothing wrong with one large dll, given the amount of memory, diskspace available nowadays.

Answer 6

For stuff that is shared in multiple projects I generally go with the one big DLL approach. Here's the rub though, if you have many projects using this guy, I highly recommend strong naming it and tossing it into the GAC. What you'll eventually run into as you add more and more projects is the desire to make a breaking change to a shared component. If you aren't using strong naming/GAC, then you have to go and update every app when you make the change, and inevitably you'll forget one, and something in production will explode.

Strong name it, keep a release version in a centralized folder in source control, and always reference that. Then on deploy toss it in the GAC.