Out of all the post that I have made so far none is on any technical topic. Hence thought of writing one today and in the future I will make some more post as well. Ok , lets get to the subject directly.
We all know that Software programming is popular very much in this century , and some people who do this like it while others even if they do it they don't really like it. Anyway for both of these type of people hopefully this post will be useful.
When it comes to programming most of us forget about Design Patterns , or even if we know that we don't get to use them. This could be due to various reason such as you just don't want to use them , or just don't have enough time to think sharp and apply them or just anything else. Anyways today lets forget about all these and try to learn something about them so that we could use it in future (I hope so :) )
There are various design patterns , out of which some are recurring most often and other are not so much. One Design Pattern that we find difficult to understand is "Visitor". The truth is may be you know the class digram for the "Visitor" pattern , but you may not really know the purpose of it. Let's first get the purpose clear ,
why we use "Visitor" pattern ,
"We use Visitor pattern to separate an Object/Class structure from it's Operations". Ok , this is bit cryptic and much more academic. Then , in layman's terms what the hell does this mean ....
lets say you have bunch of classes , which are some way related to each other , or which has some sort of a relationship to each other and you want to execute a piece of logic on all of them , or some of them. may be the operation is such that it is very unstable , susceptible to changes as the requirement changes or when your boss asks you to change. Then what to do , can we keep this operation inside the object/class structure and be happy that the object/class structure will not be changed? Nope, it will have to be changed since now the operation is also coupled in side the object/class structure as a monolithic unit.
So, in order to have your classes not disturbed by the occasional changes in the logic , why not take out the operation from the class structure and have them encapsulated in another place. In that way if you or your boss wants to change the operation , you only have to change the class in which the operation is defined now.
In a way your object structure is safe from changes now, only the operations defined elsewhere would be changed.
Now this is what we call "Visitor" pattern where every class which encapsulates different operation is a Visitor while your object structure is the Subject.
mmm... let's see this in a piece of code ....
/*
This class is a class which can accept a visitor. You can send any number of classes
which implements Visitor interface and define any operations in them
*/
package com.scea.gof.behavioral.visitor;
public class Student implements AcceptVisitor{
private String name;
private String address;
private String contactNo;
private String email;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getAddress() {
return address;
}
public void setAddress(String address) {
this.address = address;
}
public String getContactNo() {
return contactNo;
}
public void setContactNo(String contactNo) {
this.contactNo = contactNo;
}
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
-----------------Visitor Interface----------------------
/*
An interface which helps your to mark a Class or a set of Classes
as receptive to different visitors
*/
package com.scea.gof.behavioral.visitor;
public interface Visitor {
public void visit(Student student);
}
------------------------
Example Visitor having a specific operation
public class MySpecificOperation1Visitor implements Visitor{
public void visit(Student student){
//Write My operation 1 logic
}
}
public class MySpecificOperation2Visitor implements Visitor{
public void visit(Student student){
//Write My operation 2 logic
}
}
Now you see the above operations are separate and you can change them individually without worrying about the class on which those operations are performed.This way you could decouple the Operations and the Class structure.
Some people argue that keeping operations encapsulated in the class it self is a better approach towards the encapsulation philosophy , but on the other hand the solution to frequnely changing operations is none other than the Visitor pattern. Well however , the decision is up to you :)
No comments:
Post a Comment