Circular dependencies versus DRY

Question

I'm designing a re-usable class library that contains 2 assemblies (amongst others) named core.xml.dll and core.string.dll.

The xml assembly references the string assembly in order to use some string helper methods.

However now there is an string method that would be benefit from using a method contained in the xml assembly.

If I reference the xml assembly from the string assembly I will have created a circular dependency and will be unable to build both assemblies from source code. (ie chicken and the egg problem).

In order to follow the "Don't Repeat Yourself" principle I would like to avoid duplicating the functionality in both assemblies. If I find a bug in the implementation I only want to fix it in one place.

While I could merge the assemblies into one, this is not ideal as it reduces the cohesiveness of the assembly.

I would need to re-build and re-deploy the entire assembly just for a small change to a specific class. Also, eventually, with so many dependencies I would probably end up with one huge library assembly.

So in the context of a re-usable set of library assemblies what is the best approach to use here? Also, how does the .NET framework itself deal with this issue?

(In Reflector it appears that System.Configuration.dll references System.XML.DLL and vice versa. Is this actually correct, if so how is the circular dependency managed?)

Answer 1

Agree with Knives. Circular depedencies is a design smell. Refactor it Mercilessly!

This can be challenging in the case where business objects are tightly coupled. In most cases this can be solved through dependency injection.

Pseudo C++ Example:

class Employee {
    Company company;
};

class Company {
    vector<Employee> employees;
};

Tricky? Not neccesarily:

template<class CompanyT>
class Employee {
    CompanyT company;
};

class Company {
    vector<Employee<Company> > employees;
};

More primitive types, which must depend on a higher level, can be abstracted to work with any sort of other type, so long as it fulfills its contracts.

Answer 2

Sounds like you need a third assembly...

Answer 3

If your String library really needs your XML library, it is probably an indication that your String library needs to be refactored into a lower-level data type definition and "core utilities" (no external dependencies, if possible), and another higher-level library that may bring in XML, SQL, regular expressions, or whatever else you find useful at the application layer.

Answer 4

Make it an extension method that is defined in the xml assembly (based on your comment "conversion method that accepts XML and converts to a string based format"). It is dealing with xml. Just like Linq does for IEnumerable.