Home > Archive > Software Engineering > December 2007 > Cyclic dependencies are evil: arguing the case
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Cyclic dependencies are evil: arguing the case
|
|
| apm35@student.open.ac.uk 2007-12-05, 10:09 pm |
| I hope that most of the readers of this group will agree that cyclic
dependencies are evil, even if they can cite exceptions. What I am
after is some book or web resource where all the arguments and
discussion is gathered in one place. The closest I know of is the book
by John Lakos, Large Scale C++ Development, but this book is very old
and uses an ancient dialect of C++ (not its fault, its the way things
were at the time). This book goes into excruciating detail on the
subject but there are several reasons I cannot use it with the
argument I about to have with my colleagues:
o the book is C++ only. My current project is java.
o the book covers the issue mainly from the practical compile
and test issues of C++.
Not all these issues exist with java (e.g you do not have
headers that wind up including themselves).
o What I am after is why the principle applies to sw
engineering as a whole and is actually
independent of the language used.
o The book is very large and has been critised to belabouring
this point somewhat.
I am after some more concise arguments.
For example, one reason why cyclic dependencies are evil which does
not seem to get much mention is that if A depends on B and B depends
on A then neither can be tested independently.
Regards,
Andrew Marlow
| |
| Phlip 2007-12-05, 10:09 pm |
| apm35@student.open.ac.uk wrote:
> ...John Lakos, Large Scale C++ Development, but this book is very old
> o the book is C++ only. My current project is java.
Java is a watered-down C++. The rationals for C++'s physical design are much
the same for Java.
> o the book covers the issue mainly from the practical compile
> and test issues of C++.
So you have a wall-to-wall test rig for Java, right?
> Not all these issues exist with java (e.g you do not have
> headers that wind up including themselves).
Look up "Liskov Substitution Principle", "Dependency Inversion Principle",
and "Law of Demeter".
> o What I am after is why the principle applies to sw
> engineering as a whole and is actually
> independent of the language used.
Because it's not just management of cyclic dependencies. It's about managing
dependencies of any kind. To add features, you should not have to change
too many parts of the code, and you should totally not have to change one
part of the code only because you changed another. The code should be
flexible and easy to extend.
So also look up "Refactoring", and "Refactoring to Patterns".
> o The book is very large and has been critised to belabouring
> this point somewhat.
> I am after some more concise arguments.
>
> For example, one reason why cyclic dependencies are evil which does
> not seem to get much mention is that if A depends on B and B depends
> on A then neither can be tested independently.
Only the strictest kind of Quality Assurance Unit Tests need that level of
detail. If a test reports A broke, you should never need to track the bug
into B. The test should isolate its unit.
That's too hard for normal testing. Just let test cases call A calling B,
and run the tests after every change. If the tests fail unexpectedly, you
can revert back the last change, without examining A or B. You can also
easily find the problem by examining your last edit, whether in A or B.
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath
| |
| H. S. Lahman 2007-12-05, 10:09 pm |
| Responding to Apm35...
> I hope that most of the readers of this group will agree that cyclic
> dependencies are evil, even if they can cite exceptions. What I am
> after is some book or web resource where all the arguments and
> discussion is gathered in one place. The closest I know of is the book
> by John Lakos, Large Scale C++ Development, but this book is very old
> and uses an ancient dialect of C++ (not its fault, its the way things
> were at the time). This book goes into excruciating detail on the
> subject but there are several reasons I cannot use it with the
> argument I about to have with my colleagues:
>
> o the book is C++ only. My current project is java.
> o the book covers the issue mainly from the practical compile
> and test issues of C++.
> Not all these issues exist with java (e.g you do not have
> headers that wind up including themselves).
> o What I am after is why the principle applies to sw
> engineering as a whole and is actually
> independent of the language used.
> o The book is very large and has been critised to belabouring
> this point somewhat.
> I am after some more concise arguments.
The book is also one of the most authoritative sources on the subject,
regardless of age. The principles Lakos discusses are readily extended
other dialects of C++, Java, and other OOPLs; C++ just happens -- as
usual -- to be the worst offender.
As Phlip points out, you can google subtopics like LSP, DIP, and LoD.
However, they only address specific aspects of cyclic dependencies that
Lakos addresses in general. You might also check Acyclic Dependencies
Principle (ADP) in Martin's "Agile Software Development: Principle,
Patterns, and Practices" -- which happens to use primarily Java in its
examples.
> For example, one reason why cyclic dependencies are evil which does
> not seem to get much mention is that if A depends on B and B depends
> on A then neither can be tested independently.
Actually, this is not necessarily correct. It all depends on the
/nature/ of the dependency and where the observer is standing. For
example, if the only dependency is that each knows the other's interface
so that each can send a message to the other (i.e., neither
implementation depends in any way on what the other does in response to
the message), then the cyclic dependency is pretty benign. Thus in the
OOA/D such a cyclic dependency is not something one would worry about.
However, due to physical coupling in the 3GL type systems (largely due
to procedural message passing where message and method are not
separated), in many OOPLs that interface cannot be known without
substantial type coupling. It is that type coupling that tends to drive
refactoring techniques to eliminate the cycle even though there is no
implementation dependency. To that extent your concerns about specific
languages are justified. OTOH, the entire C-based family of OOPLs shares
essentially the same sort of type system coupling issues as C++ (i.e.,
the interfaces are described in header files that also describe
implementation, such as virtual name table offset). So what is true for
one of them is very likely true for the rest.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
| apm35@student.open.ac.uk 2007-12-06, 4:28 am |
| On 5 Dec, 15:35, Phlip <phlip2...@gmail.com> wrote:
> So you have a wall-to-wall test rig for Java, right?
Any place where I have to argue that cyclic dependencies are evil will
not recognise the value of unit testing either. Around where I am they
score low (2) on the Joel Test.
| |
|
| apm35@student.open.ac.uk wrote:
>
> Any place where I have to argue that cyclic dependencies are evil will
> not recognise the value of unit testing either. Around where I am they
> score low (2) on the Joel Test.
What's the Joel Test?
And I bet y'all are too busy debugging to add unit tests. And cyclic
dependencies will be the least of your problems.
Change your organization, or change your organization. Just leave anyone who
won't unit test behind.
--
Phlip
| |
| apm35@student.open.ac.uk 2007-12-07, 4:23 am |
| On 6 Dec, 15:51, Phlip <phlip2...@gmail.com> wrote:
> ap...@student.open.ac.uk wrote:
>
>
> What's the Joel Test?
See http://www.joelonsoftware.com/artic...0000000043.html
> And I bet y'all are too busy debugging to add unit tests.
Whether or not a project employs the good practice of unit testing is
a cultural thing. In some projects it is the culture, in other
projects it is not. It depends on the project mgr. Some mgrs rate it
as important enough to do something about it to ensure it happens.
Others don't.
> And cyclic
> dependencies will be the least of your problems.
It's the current problem, and it's serious because it prevents the
code from building.
> Change your organization, or change your organization. Just leave anyone who
> won't unit test behind.
I'm a contractor. I will be leaving in February.
> --
> Phlip
| |
|
| >> What's the Joel Test?
>
> See http://www.joelonsoftware.com/artic...0000000043.html
Joel combines a clear, pompous writing style with an inflated, fragile ego.
He often disregards or flames things he thought his own awesome self should
have invented.
I wouldn't cite him.
|
|
|
|
|