ansaurus

Question

Answer 1

+3 A:

Sounds like you need a third assembly...

2009-03-08 04:06:49

I had though about a 3rd assembly containing Intefaces only. But doesn't this force the application (client) of both assemblies to do all the "plugging" of components together? This would require a full blown Dependency Injection framework wouldn't it?

Ash 2009-03-08 04:17:18

@Ash - try not to overengineer it in your head. If you need to convert XML -> String, that doesn't require dependency injection, that just requires one single free function (which references both String and XML libraries).

Tom 2009-03-08 04:19:46

agreed with Tom's answer, disagree with needing a third assembly, it is overkill when it might just be an extension method scenario i.e. think linq extension methods on IEnumerable ...

eglasius 2009-03-08 04:24:20

Answer 2

+5 A:

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.

TokenMacGuy 2009-03-08 04:15:48

But Iv'e found circular depencies often appear quite naturally in an object oriented design, ie Employee works for Company, Company has a number of Employees. How do you refactor without changing this sort of relationship?

Ash 2009-03-08 04:21:02

@Ash: Is the focus of your system the employee, or the company? If the former, then the employee isn't owned by the company, the company is merely one aspect of their lives. If the latter, then the company has various classes of employee, who share one or more common interfaces.

Shog9 2009-03-08 04:25:47

@Shog9, I find I create two way references in my designs quite often. But It seems you're saying that this can be a design smell and should be minimized. I'll have to think a bit more on this, thanks.

Ash 2009-03-08 04:34:10

@Ash, nothing wrong with two-way references, but often two objects referencing each other shouldn't see each other the way they see themselves. I don't agree with the folks who strive to avoid ALL explicit dependencies, but one you move beyond simple relations it's worth reducing them.

Shog9 2009-03-08 04:48:55

Answer 3

+3 A:

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.

eglasius 2009-03-08 04:18:08

Fair tip. But is there a more generally applicable software engineering approach to this issue. My example using string and xml is perhaps not the best, what about say a Settings assembly using XML assembly and vic versa?

Ash 2009-03-08 04:39:04

@Ash - a core XML module doesn't need configuration at all. An XML-based configuration makes sense. A high-level module that uses XML-based configuration to determine how to parse other XML documents will use both of those libraries.

Tom 2009-03-08 05:19:51

Answer 4

+3 A:

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.

Tom 2009-03-08 04:18:24

Good tips, thanks.

Ash 2009-03-08 04:24:58

ansaurus

tags:

views:

answers:

Circular dependencies versus DRY

related questions