tiennm99/java-design-patterns
1
0
Fork 0
mirror of https://github.com/tiennm99/java-design-patterns.git synced 2026-08-20 06:23:48 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: Improvements to Acyclic Visitor readme

Browse Source
This commit is contained in:
Ilkka Seppälä
2024-02-25 13:43:27 +02:00
parent a258bcc1eb
commit 89d9558b00
1 changed files with 4 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
acyclic-visitor/README.md
+4 -5
View File
@@ -8,8 +8,7 @@ tag:
## Intent ## Intent
Allow new functions to be added to existing class hierarchies without affecting those hierarchies, and without creating The Acyclic Visitor pattern decouples operations from an object hierarchy, allowing you to add new operations without modifying the object structure directly.
the troublesome dependency cycles that are inherent to the GoF Visitor Pattern.
## Explanation ## Explanation
@@ -135,19 +134,19 @@ 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.
## Tutorial ## Tutorials
* [Acyclic Visitor Pattern Example](https://codecrafter.blogspot.com/2012/12/the-acyclic-visitor-pattern.html) * [Acyclic Visitor Pattern Example](https://codecrafter.blogspot.com/2012/12/the-acyclic-visitor-pattern.html)
## Consequences ## Consequences
The good: Benefits:
* No dependency cycles between class hierarchies. * No dependency cycles between class hierarchies.
* No need to recompile all the visitors if a new one is added. * 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. * Does not cause compilation failure in existing visitors if class hierarchy has a new member.
The bad: Trade-offs:
* Violates [Liskov's Substitution Principle](https://java-design-patterns.com/principles/#liskov-substitution-principle) by showing that it can accept all visitors but actually only being interested in particular visitors. * Violates [Liskov's Substitution Principle](https://java-design-patterns.com/principles/#liskov-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. * Parallel hierarchy of visitors has to be created for all members in visitable class hierarchy.