A friend was asking whether I had a great way to explain recursion. I had better ways back when I was first learning it, but now it's a bit too implicit. However, here's an approximation of how I liked to look at it initially. It's programming centric, in terms of stack frames, but the helpful principle to me was expanding a function as the window into another function, and in particular, into the function of itself.
Recursion note
2012-10-07
[Technology] Visitor Pattern
Labels: #Technology, design patterns, software engineering
A friend mentioned topics in CS they are dealing with recently. One is the Visitor pattern. One of its goals is to keep categories of logic outside of objects they apply to, but which they are conceptually distinct from. Objects representing animals don't directly care about the logic of saving. Instead, you get a separate object representing the animal and one representing the logic of saving; this logic-based object is a visitor which will visit the animal to do its work.
How they interact is neat. They are both passed to one another, which is a degree of coupling I generally try to avoid. The subject (the animal) has an accept method, which it uses to accept its visitor (the logical object). The visiting logical object has a visit method, which the subject passes itself to. The visit method on the logical object then performs its logic on the subject. Yay!
One of the consequences is a plurality of methods that come into existence to handle the different combinations of subject and visitor. These blocks of logic are a little unavoidable, so the visitor pattern doesn't really help you reduce the amount of code. Instead, it just helps you organise it and it simplifies its usage. Without the visitor pattern, you might have each animal including the logic within its class as methods. With the visitor pattern, each subject has a trivial function that just passes itself to a visiting visitor that it has accepted. The visitor will have a different visit () method for each potential subject it might work on, so the subject passing itself to the visitor's visit () helps identify which logic to use.
This vague explanation is elaborated on in this Wikipedia article.
How they interact is neat. They are both passed to one another, which is a degree of coupling I generally try to avoid. The subject (the animal) has an accept method, which it uses to accept its visitor (the logical object). The visiting logical object has a visit method, which the subject passes itself to. The visit method on the logical object then performs its logic on the subject. Yay!
One of the consequences is a plurality of methods that come into existence to handle the different combinations of subject and visitor. These blocks of logic are a little unavoidable, so the visitor pattern doesn't really help you reduce the amount of code. Instead, it just helps you organise it and it simplifies its usage. Without the visitor pattern, you might have each animal including the logic within its class as methods. With the visitor pattern, each subject has a trivial function that just passes itself to a visiting visitor that it has accepted. The visitor will have a different visit () method for each potential subject it might work on, so the subject passing itself to the visitor's visit () helps identify which logic to use.
This vague explanation is elaborated on in this Wikipedia article.
Abonnieren
Posts (Atom)