Question

I’m just starting out refactoring my code into multiple assemblies, and feel a bit lost on what to put where and how to name them. Up to now I’ve just placed all common classes in a single library, but it’s time to advance on that.

So a few examples/questions to get my head started:

1. Two classes, IMessageBus and MessageBus, which is generic EventAggregator that allows subscription and publishing of messages of any type. Can be used of any project. Where to put these classes? What to name the libary, and what else would belong in that library?

2. What about modules of extension methods of common .net types, would you put all these in a single library?

3. Perhaps I’m lost on exactly what justifies to move something into a library or not, I’m basically just thinking “reuse”. So if some more intelligent brief rules could be noted, would be helpful.

---

EDIT:

Yes my reasons are kind of vague, that’s why I look for advice. Of course one common library satisfies reuse, so there should be other justification. I’m making a handful of applications that all use the same common library. One app will be distributed to external users, and hence I must force them to update when I find bugs. For this reason I thought sometimes I may be unable to know if a bug affects that program, as I don’t remember exactly what part of the common library is utilized. So if I instead have many smaller libraries, it may be easier to identify which programs are affected, to avoid pushing unnecessary updates. (?) Btw I’m not programming for costumers, so I manage all distribution myself.

Answer 1

Only split when you need it.

As with naming types, variables, files, etc: do not create it if you do not know how to call it. It is a sign of not knowing what it is and what its purpose is.

Reasons to split are: separate versioning, separate deployment and hiding types using ‘internal’