gaspersic/java-design-patterns
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Adding consequences in README.md

Browse Source
This commit is contained in:
Argyro-Sioziou 2018-06-14 17:56:14 +03:00
parent 6636fb151b
commit 04d80f05c8
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
acyclic-visitor/README.md
View File

@ -22,6 +22,16 @@ This pattern can be used:
* When the visited class hierarchy will be frequently extended with new derivatives of the Element class. * When the visited class hierarchy will be frequently extended with new derivatives of the Element class.
* When the recompilation, relinking, retesting or redistribution of the derivatives of Element is very expensive. * When the recompilation, relinking, retesting or redistribution of the derivatives of Element is very expensive.
## Consequences
The good:
* No dependency cycles between class hierarchies.
* No need to recompile all the visitors if a new one is added.
* Does not cause compilation failure in existing visitors if class hierarchy has a new member.
The bad:
* Violates the principle of least surprise or Liskov's Substitution principle by showing that it can accept all visitors but actually only being interested in particular visitors.
* Parallel hierarchy of visitors has to be created for all members in visitable class hierarchy.
## Related patterns ## Related patterns
* [Visitor Pattern](../visitor/README.md) * [Visitor Pattern](../visitor/README.md)