Printable View
Hello!
I was coding for the chess program in C++ & i got an error because i was calling both of my classes in each other ie. Class Chess.h was calling the class Board.h & vice-versa.
Now the thing is I came to know that this is circular redundancy!
Now can anyone please explain me what is this circular redundancy?
Some architects (we're ALL architects to some degree) might hold fast to a rule of "No Circular Dependencies", and rather than have two objects dependent upon one another directly, they'll create a third object to act as the broker between them. Instead of the two objects being injected into one another, those same two objects are instead injected into the third object, who orchestrates how they work together. I wouldn't say this is a bad thing, and in fact probably makes perfect sense to do so in many situations. Bottom line, though, is that we don't have to avoid circular dependency relationships when they do make sense.
Circular dependencies are natural in many domain models where certain objects of the same domain mutually depend on each other. However, in software design circular dependencies between larger software modules are considered an anti-pattern because of their negative effects.
Circular dependencies can cause many unwanted effects in software programs. Most problematic from a software design point of view is the tight coupling of the mutually dependent modules which reduces or makes impossible the re-use of a single module as such.
Circular dependencies can cause so called domino effect when a small local change in one module spreads into other modules and has unwanted global effects (i.e. program errors, compile errors). Circular dependencies might also result in infinite recursions or in unexpected failures in software programs.
Circular dependencies may also cause memory leaks by preventing certain very primitive automatic garbage collectors (those that use reference counting) from deallocating unused objects.
Circular dependencies are often introduced by inexperienced programmers which need to implement some kind of callback functionality. Experienced programmers avoid such unnecessary circular dependencies by applying design patterns like the observer pattern.
For code example!
The term "circular dependency" may be foreign to some programmers (especially if you do Java as it is a pretty common practice). However, anyone who has done some scripting for a referential database knows that you have to run scripts in a certain order. Running scripts out of order causes errors when you run. The interesting trick is that if you run that same incorrectly-ordered DDL script again and again you will eventually get it to run without errors.
What is a circular dependency?
It is simply two libraries that use each other (either directly or indirectly) as shown below:
Application A <<==== Depends on ====>> Application B
This may go in multiple way!
Why are circular dependencies bad?
there is no such thing as a "correct" build order when there are these circular dependencies. The only way you can arrive at the correct version of the code is to build it as many times as there are nodes in our circle.
How do I fix circular dependencies?
Refactor common code into a "base" dependency; I usually call this "Common"
Remove code that is unused. In the tangles shown above many of them are using deprecated/unused code.
Duplicate the sections of code used. This should be seen as a last resort but given the choice between code duplication and circular dependencies, I take code duplication ever time!
There are two kinds of design concepts for nTier (and other types of architectures as well) called Logical Layout Design and Physical Layout Design. The Logical Layout is simply that your software occupies the same project/package but leverage different classes. In contrast Physical Layout Design forces each tier to be separated into different Projects/Packages. So long as we are careful to manage the dependencies between these packages from the start this is the preferable way to code. While the logical layout does not suffer from the dependency problem eventually you may wish to break these classes apart and find that there are a lot of inner-dependency that should not exist simply because they occupied the same project. Remember to keep it clean!