Showing posts with label Double Dispatch. Show all posts
Showing posts with label Double Dispatch. Show all posts

Saturday, 11 January 2014

Visitor Design pattern - Implementation [Products]

Master Practical Java Design Patterns!

Subscribe to Ram N Java for clean coding tutorials, behavioral design patterns, and real-world Java architecture implementations!

🔔 Subscribe to Ram N Java

The Problem: Adding Operations to Existing Classes

Imagine an e-commerce shopping cart containing various products—such as books, electronics, and fruits. Each product type has distinct pricing, shipping rules, and tax calculation formulas.

If you add new operations (like calculating discounted prices, export tariffs, or generating itemized receipts) directly into each product class, you violate the Open/Closed Principle. Every time business requirements introduce a new calculation or reporting feature, you are forced to modify and retest every product class.

The Solution: The Visitor Design Pattern

The Visitor Design Pattern separates an algorithm from the object structure on which it operates using a technique known as Double Dispatch:

  • Element Interface (Visitable): Declares an accept(Visitor visitor) method implemented by each product (e.g., Book, Fruit).
  • Visitor Interface: Defines dedicated visit methods for each concrete product type, such as visit(Book book) and visit(Fruit fruit).
  • Concrete Visitor: Encapsulates specific operational algorithms (e.g., ShoppingCartVisitor), computing costs and discounts based on the exact product type without polluting the product models.

Key Architectural Benefits

Applying the Visitor pattern to structured collections offers several advantages:

  • Open/Closed Principle: Add new operations (like tax auditing or loyalty points calculation) simply by introducing a new visitor class, leaving product classes untouched.
  • Single Responsibility Principle: Gathers related operations into a single class rather than scattering them across different element definitions.
  • Accumulated State: Visitors can maintain running states (such as running totals or item summaries) as they traverse a complex object structure.

Related Tutorials from Ram N Java



Click here to watch in Youtube : https://www.youtube.com/watch?v=tI3CRnDI3f0

Click the below Image to Enlarge
Visitor Design pattern - Implementation [Products]

Visitor Design pattern - Implementation [Products] - Class Diagram























Product.java

/*
 * Visitable Class
 */
public abstract class Product
{
protected int price;

public abstract void accept( ShoppingMallVisitor shoppingMallVisitor );

public int getPrice()
{
return price;
}
}

Book.java

public class Book extends Product
{

private String name;
private String isbnNumber;

public Book( String name, String isbnNumber, int price )
{
super();
this.name = name;
this.isbnNumber = isbnNumber;
this.price = price;
}

public String getName()
{
return name;
}

public String getIsbnNumber()
{
return isbnNumber;
}

@Override
public void accept( ShoppingMallVisitor shoppingMallVisitor )
{
shoppingMallVisitor.visit(this);
}

@Override
public String toString()
{
return "Book [name=" + name + ", isbnNumber=" + isbnNumber + ", price=" + price + "]";
}

}

DVD.java

public class DVD extends Product
{

private String name;

public DVD( String name, int price )
{
super();
this.name = name;
this.price = price;
}

public String getName()
{
return name;
}

@Override
public void accept( ShoppingMallVisitor shoppingMallVisitor )
{
shoppingMallVisitor.visit(this);
}

@Override
public String toString()
{
return "DVD [name=" + name + ", price=" + price + "]";
}

}

Shirt.java

public class Shirt extends Product
{

private String brandName;
private String size;

public Shirt( String brandName, String size, int price )
{
super();
this.brandName = brandName;
this.size = size;
this.price = price;
}

public String getBrandName()
{
return brandName;
}

public String getSize()
{
return size;
}

@Override
public void accept( ShoppingMallVisitor shoppingMallVisitor )
{
shoppingMallVisitor.visit(this);
}

@Override
public String toString()
{
return "Shirt [brandName=" + brandName + ", size=" + size + ", price=" + price + "]";
}

}

ShoppingMallVisitor.java

public interface ShoppingMallVisitor
{
public void visit(Product product);
}

Cashier.java

public class Cashier implements ShoppingMallVisitor
{

private String name;

private int    totalPrice = 0;

public int getTotalPrice()
{
return totalPrice;
}

public Cashier( String name )
{
super();
this.name = name;
}

public String getName()
{
return name;
}

@Override
public void visit( Product product )
{
totalPrice = totalPrice + product.getPrice();
}

}

ShoppingMallProducts.java

import java.util.ArrayList;
import java.util.LinkedHashMap;

public class ShoppingMallProducts
{

static LinkedHashMap<String, Product> productMap;

static
{
productMap = new LinkedHashMap<String, Product>();

Book weArebackBook = new Book("We are Back", "ISBN-999", 200);
Book jesusStoryBook = new Book("Jesus Story", "ISBN-1999", 500);
Book moralStoryBook = new Book("Moral Story", "ISBN-2999", 600);

DVD dieHard2Dvd = new DVD("Die Hard 2", 100);
DVD terminatorDvd = new DVD("The Terminator", 150);
DVD titanicDvd = new DVD("Titanic", 120);

Shirt zeroShirt = new Shirt("Zero", "42", 1500);
Shirt peterEnglandShirt = new Shirt("Peter England", "42", 2500);
Shirt johnPlayersShirt = new Shirt("John Players", "40", 2500);

productMap.put("weArebackBook", weArebackBook);
productMap.put("jesusStoryBook", jesusStoryBook);
productMap.put("moralStoryBook", moralStoryBook);
productMap.put("dieHard2Dvd", dieHard2Dvd);
productMap.put("terminatorDvd", terminatorDvd);
productMap.put("titanicDvd", titanicDvd);
productMap.put("zeroShirt", zeroShirt);
productMap.put("peterEnglandShirt", peterEnglandShirt);
productMap.put("johnPlayersShirt", johnPlayersShirt);

}

public int getTotalAmount( ArrayList<Product> purchasedProductList )
{
Cashier cashier = new Cashier("John");

System.out.println("Puschased Products details : \n");
for( Product product : purchasedProductList )
{
// Each product accepts the visitor
product.accept(cashier);
System.out.println(product+"\n");
}

return cashier.getTotalPrice();
}

}


Client.java

import java.util.ArrayList;
import java.util.LinkedHashMap;
import java.util.Set;


public class Client
{

public static void main( String[] args )
{
LinkedHashMap<String, Product> productMap = ShoppingMallProducts.productMap;
Set<String> products=productMap.keySet();
System.out.println("Products Available \n");
for( String string : products )
                {
System.out.println(productMap.get(string));
                }
System.out.println(" \n############################################################# \n");
ArrayList<Product>    purchasedProductList = new ArrayList<Product>();
purchasedProductList.add(productMap.get("weArebackBook"));
purchasedProductList.add(productMap.get("jesusStoryBook"));
purchasedProductList.add(productMap.get("dieHard2Dvd"));
purchasedProductList.add(productMap.get("terminatorDvd"));
purchasedProductList.add(productMap.get("zeroShirt"));
purchasedProductList.add(productMap.get("peterEnglandShirt"));
ShoppingMallProducts shoppingMallProducts = new ShoppingMallProducts();
System.out.println("Total Amount : "+shoppingMallProducts.getTotalAmount(purchasedProductList) + "Rs");
}

}


Output

Products Available 

Book [name=We are Back, isbnNumber=ISBN-999, price=200]
Book [name=Jesus Story, isbnNumber=ISBN-1999, price=500]
Book [name=Moral Story, isbnNumber=ISBN-2999, price=600]
DVD [name=Die Hard 2, price=100]
DVD [name=The Terminator, price=150]
DVD [name=Titanic, price=120]
Shirt [brandName=Zero, size=42, price=1500]
Shirt [brandName=Peter England, size=42, price=2500]
Shirt [brandName=John Players, size=40, price=2500]
############################################################# 

Puschased Products details : 

Book [name=We are Back, isbnNumber=ISBN-999, price=200]

Book [name=Jesus Story, isbnNumber=ISBN-1999, price=500]

DVD [name=Die Hard 2, price=100]

DVD [name=The Terminator, price=150]

Shirt [brandName=Zero, size=42, price=1500]

Shirt [brandName=Peter England, size=42, price=2500]

Total Amount : 4950Rs


See also:

  • Visitor Design pattern - Introduction
  • Visitor Design pattern - Real time Example [Kids]
  • Visitor Design pattern - Real time Example [Products]
  • Visitor Design pattern - Class Diagram
  • Visitor Design pattern - Implementation [Kids]
  • Visitor Design pattern - KeyPoints
  • All Design Patterns Links
  • Friday, 10 January 2014

    Visitor Design pattern - Implementation [Kids]

    Master Real-World Java Design Patterns!

    Subscribe to Ram N Java for intuitive programming tutorials, behavioral design patterns, and practical Java architecture implementations!

    🔔 Subscribe to Ram N Java

    The Scenario: A Doctor Visiting Different Patient Categories

    Consider a healthcare system where various types of patients—such as children, adults, and senior citizens—need medical assessments. Each category of patient requires distinct checkup protocols, diagnostic tests, and dosage considerations.

    If you hardcode checkup procedures directly into the patient classes, you quickly run into architectural bottlenecks. Whenever medical regulations update, or a new specialist (e.g., a dentist or cardiologist) visits the patient, you would be forced to open and modify every patient class, directly violating the Open/Closed Principle.

    The Solution: Applying the Visitor Pattern

    The Visitor Design Pattern separates medical assessment logic from the patient data models by utilizing Double Dispatch:

    • Visitable Element (Patient): Each patient class defines an accept(Visitor visitor) method, passing itself to the visiting medical practitioner.
    • Visitor Interface (Doctor): Declares specialized visit operations for each concrete patient type (e.g., visit(ChildPatient patient), visit(SeniorPatient patient)).
    • Concrete Visitor (GeneralPhysician / Specialist): Implements the specific medical assessment or treatment routines tailored to the specific patient type without altering the patient's internal structure.

    Architectural Advantages in Practice

    Using the Visitor pattern for domain modeling offers key architectural benefits:

    • Open/Closed Principle: Introduce new doctors, health inspectors, or billing visitors without modifying existing patient classes.
    • Single Responsibility Principle: Gathers related diagnostic and medical checkup operations into dedicated visitor classes instead of bloating data models.
    • Extensible Operations: Easy to introduce new operations (like health index calculations or vaccination audits) across an entire group of patient objects.

    Related Tutorials from Ram N Java


    Click here to watch in Youtube : https://www.youtube.com/watch?v=P8ScJp-p1So

    Click the below Image to Enlarge
    Visitor Design pattern - Implementation [Kids]


    Visitor Design pattern - Implementation [Kids] - Class Diagram


































    Visitable.java


    public interface Visitable
    {
    public void accept(Visitor visitor);
    }

    Child.java

    public class Child implements Visitable
    {

    private String name;

    private String healthStatus;

    public Child( String name )
    {
    super();
    this.name = name;
    }

    public String getName()
    {
    return name;
    }

    public String getHealthStatus()
    {
    return healthStatus;
    }

    public void setHealthStatus( String healthStatus )
    {
    this.healthStatus = healthStatus;
    }

    @Override
    public void accept( Visitor visitor )
    {
    visitor.visit(this);
    }

    }

    Visitor.java

    public interface Visitor
    {
    public void visit(Visitable visitable);
    }

    ChildSpecialistDoctor.java

    public class ChildSpecialistDoctor implements Visitor
    {

    private String name;

    public ChildSpecialistDoctor( String name )
    {
    super();
    this.name = name;
    }

    public String getName()
    {
    return name;
    }

    @Override
    public void visit( Visitable visitable )
    {
    Child child = (Child) visitable;
    child.setHealthStatus("Bad");
    System.out.println("ChildSpecialistDoctor: '" + this.getName() + "' did the checkup of the child: '"
                   + child.getName()
                   + "' and found health is not good so updated the health status as 'Bad'\n");

    }

    }

    School.java

    import java.util.ArrayList;

    public class School
    {

    static ArrayList<Child> childList;
    static
    {
    childList = new ArrayList<Child>();

    Child john = new Child("John");
    Child steve = new Child("Steve");
    Child rohit = new Child("Rohit");
    Child sonu = new Child("Sonu");

    childList.add(john);
    childList.add(steve);
    childList.add(rohit);
    childList.add(sonu);
    }
    public static void doHealthCheckup()
    {
    ChildSpecialistDoctor childSpecialistDoctor = new ChildSpecialistDoctor("Dr.Smith");
    for( Child child : childList )
                    {
                   child.accept(childSpecialistDoctor);
                    }
    }

    }

    Client.java

    public class Client
    {

    public static void main( String[] args )
    {
    School.doHealthCheckup();
    }

    }

    Output

    ChildSpecialistDoctor: 'Dr.Smith' did the checkup of the child: 'John' and found health is not good so updated the health status as 'Bad'

    ChildSpecialistDoctor: 'Dr.Smith' did the checkup of the child: 'Steve' and found health is not good so updated the health status as 'Bad'

    ChildSpecialistDoctor: 'Dr.Smith' did the checkup of the child: 'Rohit' and found health is not good so updated the health status as 'Bad'

    ChildSpecialistDoctor: 'Dr.Smith' did the checkup of the child: 'Sonu' and found health is not good so updated the health status as 'Bad'


    See also:

  • Visitor Design pattern - Introduction
  • Visitor Design pattern - Real time Example [Kids]
  • Visitor Design pattern - Real time Example [Products]
  • Visitor Design pattern - Class Diagram
  • Visitor Design pattern - Implementation [Products]
  • Visitor Design pattern - KeyPoints
  • All Design Patterns Links
  • Visitor Design pattern - Class Diagram

    Master UML Class Diagrams & Architecture!

    Subscribe to Ram N Java for clean class diagrams, design pattern tutorials, and real-world coding guides!

    🔔 Subscribe to Ram N Java

    Anatomy of the Visitor Class Diagram

    The Visitor Design Pattern represents an operation to be performed on the elements of an object structure without changing the classes of the elements on which it operates. The UML class diagram breaks this relationship down into five fundamental participants:

    • Visitor Interface: Declares a set of visiting methods (e.g., visitConcreteElementA(), visitConcreteElementB()), with each method corresponding to a specific concrete element class.
    • ConcreteVisitor: Implements each visit method declared by the Visitor interface to execute a specific algorithm across elements.
    • Element Interface: Declares an accept(Visitor visitor) method that takes a visitor interface as an argument.
    • ConcreteElement: Implements the accept() method by invoking the corresponding visit method on the visitor, passing itself as a parameter (visitor.visitConcreteElement(this)).
    • ObjectStructure: Holds a collection of elements and provides high-level interfaces allowing visitors to traverse the structure.

    The Double Dispatch Mechanism

    The core dynamic powering the Visitor class diagram is Double Dispatch, which determines the executed operation based on two receiver types:

    1. First Dispatch: The client asks an element to accept a visitor: element.accept(visitor). Polymorphism resolves the specific ConcreteElement type at runtime.
    2. Second Dispatch: Inside the element's accept() method, it calls back to the visitor: visitor.visit(this). Method overloading and polymorphism resolve the exact ConcreteVisitor and method implementation.

    Architectural Benefits and Trade-offs

    Understanding the structural design of the Visitor pattern highlights key advantages and considerations:

    • Open/Closed Principle: Easily introduce new operations by writing new concrete visitor classes without touching existing element hierarchies.
    • Single Responsibility Principle: Gathers related operations into a single class rather than scattering them across various element classes.
    • Structure Stability Requirement: While adding new operations (visitors) is straightforward, adding a new element class requires updating the Visitor interface and every existing concrete visitor.

    Related Tutorials from Ram N Java


    Click here to watch in Youtube : https://www.youtube.com/watch?v=jVQ7Q6GBuEY

    Click the below Image to Enlarge
    Visitor Design pattern - Class Diagram


















    See also:

  • Visitor Design pattern - Introduction
  • Visitor Design pattern - Real time Example [Kids]
  • Visitor Design pattern - Real time Example [Products]
  • Visitor Design pattern - Implementation [Kids]
  • Visitor Design pattern - Implementation [Products]
  • Visitor Design pattern - KeyPoints
  • All Design Patterns Links
  • Tuesday, 7 January 2014

    Visitor Design pattern - Real time Example [Products]

    Master Practical Java Design Patterns!

    Subscribe to Ram N Java for clean coding tutorials, behavioral design patterns, and real-world system architecture walkthroughs!

    🔔 Subscribe to Ram N Java

    The Product Management Challenge

    In real-world inventory and e-commerce product management systems, applications handle a diverse catalog of items—such as electronics, groceries, apparel, and books. Each product category carries unique business rules for pricing, discounts, shipping tariffs, and tax compliance.

    When new operational requirements arise—like computing holiday discounts, generating export summaries, or calculating environmental recycling fees—modifying individual product classes directly clutters domain models and violates the Open/Closed Principle.

    How the Visitor Pattern Organizes Operations

    The Visitor Design Pattern decouples new operational logic from the core product models using Double Dispatch:

    • Visitable Element Hierarchy: Concrete product classes (e.g., ElectronicItem, GroceryItem) implement an accept(Visitor visitor) method, passing themselves to the visitor.
    • Visitor Interface: Specifies dedicated visit operations for each concrete product class (e.g., visit(ElectronicItem item), visit(GroceryItem item)).
    • Concrete Operations (Visitors): Encapsulate distinct algorithms—such as a DiscountCalculatorVisitor or a TaxReportVisitor—processing products according to their concrete type without changing their class definitions.

    Key Architectural Benefits

    Applying the Visitor pattern to product management architectures delivers major advantages:

    • Open/Closed Principle: Seamlessly plug in new reporting, pricing, or auditing operations simply by adding a new visitor implementation.
    • Separation of Concerns: Keeps core product domain classes clean and focused strictly on data representation rather than volatile business rules.
    • Centralized Operation Logic: Groups related business computations into focused classes rather than scattering them across dozens of item models.

    Related Tutorials from Ram N Java


    Click here to watch in Youtube : https://www.youtube.com/watch?v=J3hIii4zLD8

    Click the below Image to Enlarge
    Visitor Design pattern - Real time Example [Products]


















    See also:

  • Visitor Design pattern - Introduction
  • Visitor Design pattern - Real time Example [Kids]
  • Visitor Design pattern - Class Diagram
  • Visitor Design pattern - Implementation [Kids]
  • Visitor Design pattern - Implementation [Products]
  • Visitor Design pattern - KeyPoints
  • All Design Patterns Links
  • Visitor Design pattern - Real time Example [Kids]

    Master Practical Java Design Patterns!

    Subscribe to Ram N Java for clean coding tutorials, behavioral design patterns, and intuitive real-world analogies!

    🔔 Subscribe to Ram N Java

    The Analogy: A Doctor Visiting Patients

    Imagine a hospital setting where different categories of patients reside—such as children, adults, and elderly patients. When a doctor visits the ward, the examination procedure changes depending on who is being evaluated:

    • A child might require gentler diagnostic checks and pediatric wellness checks.
    • An adult patient might require blood pressure and general health screening.
    • A senior citizen might need specialized cardiovascular monitoring and mobility checks.

    If you placed the detailed medical checkup algorithms inside the patient classes themselves, the patient models would quickly become bloated with medical rules, treatment procedures, and diagnostic steps that don't belong to their core identity.

    How the Visitor Pattern Models the Doctor's Visit

    The Visitor Design Pattern models this interaction cleanly by externalizing the operation into a visitor:

    • The Element (Patient): Patients simply implement an accept(Doctor doctor) method. When the doctor arrives, the patient accepts the visit and calls doctor.visit(this).
    • The Visitor (Doctor): The doctor defines overloaded visit() methods tailored to each patient type.
    • Double Dispatch in Action: The operation executed depends on both the type of doctor visiting and the specific type of patient being examined.

    Key Architectural Takeaways

    This real-world perspective illustrates why the Visitor pattern is so effective in software engineering:

    • Open/Closed Principle: You can send a new type of visitor (e.g., a Specialist, Surgeon, or Health Inspector) to examine existing patients without modifying patient classes.
    • Single Responsibility Principle: Keeps data structures focused solely on representing domain state, while procedural and analytical algorithms stay within visitor classes.
    • Extensible Behavioral Operations: New operations across structured object hierarchies can be plugged in seamlessly.

    Related Tutorials from Ram N Java


    Click here to watch in Youtube : https://www.youtube.com/watch?v=SbXIw9EoQog

    Click the below Image to Enlarge
    Visitor Design pattern - Real time Example [Kids]


















    See also:

  • Visitor Design pattern - Introduction
  • Visitor Design pattern - Real time Example [Products]
  • Visitor Design pattern - Class Diagram
  • Visitor Design pattern - Implementation [Kids]
  • Visitor Design pattern - Implementation [Products]
  • Visitor Design pattern - KeyPoints
  • All Design Patterns Links
  • Visitor Design pattern - Introduction

    Master Object-Oriented Software Design!

    Subscribe to Ram N Java for in-depth design pattern breakdowns, clean coding principles, and practical Java tutorials!

    🔔 Subscribe to Ram N Java

    What is the Visitor Design Pattern?

    The Visitor Design Pattern is a behavioral design pattern defined by the Gang of Four (GoF). Its primary purpose is to let you define a new operation without changing the classes of the elements on which it operates.

    In traditional object-oriented programming, adding a new feature across a hierarchy of classes requires editing each class directly. Over time, this leads to bloated classes, tight coupling, and frequent violations of the Open/Closed Principle. The Visitor pattern resolves this by separating the algorithm from the object structure itself.

    Key Concepts: How the Pattern Operates

    The architecture relies on a collaborative mechanism called Double Dispatch:

    • Element Hierarchy: Classes in your domain model implement a simple accept(Visitor visitor) method.
    • Visitor Contract: An interface specifying overloaded visit(...) methods for each concrete element type.
    • Separation of Concerns: Business calculations, data exports, or auditing routines live inside concrete visitor classes instead of polluting core entity classes.

    Why Use the Visitor Pattern?

    Introducing the Visitor pattern into your architecture offers significant software engineering benefits:

    • Open/Closed Principle: Add brand-new operations across existing object structures without altering or recompiling element classes.
    • Single Responsibility Principle: Keep domain models clean and focused strictly on data representation, while algorithms reside in dedicated visitor components.
    • Accumulated State: A visitor can easily track state and calculate running metrics (such as totals or reports) while traversing complex collections.

    Related Tutorials from Ram N Java


    Click here to watch in Youtube : https://www.youtube.com/watch?v=ZHQEXEArzyw

    Click the below Image to Enlarge
    Visitor Design pattern - Introduction


















    See also:

  • Visitor Design pattern - Real time Example [Kids]
  • Visitor Design pattern - Real time Example [Products]
  • Visitor Design pattern - Class Diagram
  • Visitor Design pattern - Implementation [Kids]
  • Visitor Design pattern - Implementation [Products]
  • Visitor Design pattern - KeyPoints
  • All Design Patterns Links
  • Wednesday, 1 January 2014

    Visitor Design pattern - Keypoints

    Master Object-Oriented Software Architecture!

    Subscribe to Ram N Java for clean coding principles, GoF design patterns, and in-depth software engineering concepts!

    🔔 Subscribe to Ram N Java

    Core Intent and Architectural Purpose

    The Visitor Design Pattern is a behavioral pattern defined by the Gang of Four (GoF) that lets you add operations to an object structure without modifying the structures themselves.

    While the pattern is exceptionally powerful for keeping entity classes lightweight and decoupling operational algorithms, it introduces specific architectural trade-offs that every software engineer must evaluate before implementation.

    Critical Key Points to Remember

    Keep these essential considerations in mind when working with the Visitor pattern:

    • Double Dispatch Mechanism: Execution relies on both the dynamic type of the element receiving the visitor and the dynamic type of the visitor executing the operation.
    • Open/Closed Principle for Operations: Adding new operations is straightforward—simply create a new concrete visitor class without altering existing element hierarchies.
    • Rigidity in Element Hierarchies: Adding a new element class requires updating the Visitor interface and updating every existing concrete visitor class, making it less suitable for unstable hierarchies.
    • Encapsulation Trade-off: Visitors frequently require access to the internal state of elements, which can sometimes lead to exposing getter methods or relaxing encapsulation boundaries.
    • State Accumulation: Visitors can conveniently maintain running state (such as totals, reports, or syntax trees) as they traverse a complex collection of disparate objects.

    When Should You Choose the Visitor Pattern?

    The Visitor pattern is best suited for scenarios where:

    • An object structure contains many classes of objects with differing interfaces, and you need to perform operations that depend on their concrete classes.
    • The classes defining the object structure rarely change, but you frequently need to define new operations over that structure.
    • You want to avoid cluttering domain models with unrelated algorithmic, analytical, or reporting logic.

    Related Tutorials from Ram N Java


    Click here to watch in Youtube : https://www.youtube.com/watch?v=AW4zIuMjfXg

    Click the below Image to Enlarge


















    See also:

  • Visitor Design pattern - Introduction
  • Visitor Design pattern - Real time Example [Kids]
  • Visitor Design pattern - Real time Example [Products]
  • Visitor Design pattern - Class Diagram
  • Visitor Design pattern - Implementation [Kids]
  • Visitor Design pattern - Implementation [Products]
  • All Design Patterns Links
  • Tutorials