Design Pattern <\/a>pays off. Add a completely new operation by creating one new Visitor class. Zero changes to House, Shop, or Factory.<\/p>\n\n\n\nPython code<\/p>\n\n\n\n
class PropertyReport(Visitor):\n def visit_house(self, house):\n print(f\"House report: {house.area} sqm residential property\")\n\n def visit_shop(self, shop):\n print(f\"Shop report: Revenue of Rs. {shop.revenue}\")\n\n def visit_factory(self, factory):\n print(f\"Factory report: Employs {factory.workers} workers\")\n\n# Same elements, new visitor\nreporter = PropertyReport()\nfor property in properties:\n property.accept(reporter)\n<\/code><\/pre>\n\n\n\nOutput:<\/strong><\/p>\n\n\n\nHouse report: 120 sqm residential property\nShop report: Revenue of Rs. 50000\nFactory report: Employs 30 workers\n<\/code><\/pre>\n\n\n\nNew operation. One new class. Nothing else changed. This is the core value of the Visitor Method Design Pattern.<\/p>\n\n\n\n
Riddle: <\/em><\/strong>You have a shopping cart with three item types: Book, Electronics, and Clothing. You need to calculate the total price, apply discounts, and generate an invoice. Without the Visitor Method Design Pattern, how many methods do you add across all classes? With it, how many classes do you add?<\/em><\/p>\n\n\n\nAnswer:<\/em><\/strong> Without the visitor: 3 methods \u00d7 3 classes = 9 changes across your codebase. With the Visitor Method Design Pattern: 3 new Visitor classes, zero changes to Book, Electronics, or Clothing. Every future operation is also one new class. The objects stay stable.<\/em><\/p>\n\n\n\nA Real Example: Shopping Cart<\/strong><\/h2>\n\n\n\nHere is a practical version using items in a shopping cart.<\/p>\n\n\n\n
Python code<\/p>\n\n\n\n
# Elements\nclass Book:\n def __init__(self, price):\n self.price = price\n\n def accept(self, visitor):\n visitor.visit_book(self)\n\nclass Electronics:\n def __init__(self, price):\n self.price = price\n\n def accept(self, visitor):\n visitor.visit_electronics(self)\n\nclass Clothing:\n def __init__(self, price):\n self.price = price\n\n def accept(self, visitor):\n visitor.visit_clothing(self)\n\n# Visitor: calculates discounted price\nclass DiscountVisitor:\n def visit_book(self, book):\n print(f\"Book: Rs. {book.price * 0.9:.0f} (10% off)\")\n\n def visit_electronics(self, item):\n print(f\"Electronics: Rs. {item.price * 0.85:.0f} (15% off)\")\n\n def visit_clothing(self, item):\n print(f\"Clothing: Rs. {item.price * 0.8:.0f} (20% off)\")\n\n# Usage\ncart = [Book(500), Electronics(20000), Clothing(1200)]\ndiscount = DiscountVisitor()\n\nfor item in cart:\n item.accept(discount)\n<\/code><\/pre>\n\n\n\nOutput:<\/strong><\/p>\n\n\n\nBook: Rs. 450 (10% off)\nElectronics: Rs. 17000 (15% off)\nClothing: Rs. 960 (20% off)\n<\/code><\/pre>\n\n\n\nEach item type gets its own discount rule. Adding a new item type (like FoodItem) means adding one new visit_food()<\/strong> method to existing visitors. Adding a new operation (like tax calculation) means creating one new Visitor class.<\/p>\n\n\n\nWhen to Use the Visitor Method Design Pattern<\/strong><\/h2>\n\n\n\n\nWhen you need to add operations to a stable set of classes<\/strong> without modifying them<\/li>\n\n\n\nWhen an operation spans many unrelated classes<\/strong> and you do not want to scatter that logic across all of them<\/li>\n\n\n\nWhen you have many distinct operations<\/strong> on the same group of objects (tax, audit, export, report, print)<\/li>\n\n\n\nCompilers and interpreters:<\/strong> Each node in an abstract syntax tree (AST) accepts visitors for type checking, code generation, and optimisation<\/li>\n\n\n\nDocument export systems:<\/strong> A document tree accepts an HTML visitor, a PDF visitor, or a Markdown visitor without the nodes knowing the format<\/li>\n<\/ul>\n\n\n\nWhen NOT to Use the Visitor Method Design Pattern<\/strong><\/h2>\n\n\n\n\nWhen your element classes change frequently:<\/strong> Every time you add a new element type, you must update every existing Visitor class to add the new visit method. If the object structure is unstable, the pattern creates more work than it saves.<\/li>\n\n\n\nWhen there is only one operation:<\/strong> If you only ever need to do one thing to your objects, the Visitor Method Design Pattern is overkill.<\/li>\n\n\n\nWhen objects are simple:<\/strong> A small flat list of similar objects does not need the visitor structure.<\/li>\n<\/ul>\n\n\n\nQuick Reference: The 4 Parts<\/strong><\/h2>\n\n\n\nPart<\/strong><\/td>Role<\/strong><\/td>In the Tax Example<\/strong><\/td><\/tr>Visitor interface<\/td> Declares one visit method per element type<\/td> Visitor with visit_house, visit_shop, visit_factory<\/td><\/tr> Concrete Visitor<\/td> Implements the actual operation<\/td> TaxCalculator, PropertyReport<\/td><\/tr> Element interface<\/td> Declares the accept(visitor) method<\/td> Element base class<\/td><\/tr> Concrete Element<\/td> Calls the right visit method on the visitor<\/td> House, Shop, Factory<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTips for Using the Visitor Method Design Pattern<\/strong><\/h2>\n\n\n\n\nUse it when your objects are stable but operations keep growing:<\/strong> If new classes get added often, consider a different approach. The Visitor Method Design Pattern works best when the element types are fixed.<\/li>\n\n\n\nName your visitors clearly:<\/strong> TaxCalculator<\/strong>, InvoiceGenerator<\/strong>, XMLExporter<\/strong> are clear. Visitor1<\/strong> is not. Clear names make your visitor list self-documenting.<\/li>\n\n\n\nKeep each visitor focused on one operation:<\/strong> One visitor should do one thing. Do not combine tax calculation and report generation in the same visitor class.<\/li>\n\n\n\nAccept can be one line:<\/strong> The accept()<\/strong> method in every element is always one line: call the right visit method on the visitor and pass self. Keep it exactly that simple.<\/li>\n<\/ul>\n\n\n\n\n
\ud83d\udca1 Did You Know?<\/h3>\n \n Compilers use the Visitor Method Design Pattern heavily. When a compiler processes your code, it builds a tree of nodes (AST). Visitors then travel through that tree to perform type checking, dead code elimination, and code generation without the tree nodes knowing any of those details.<\/li>\n The Visitor Method Design Pattern is sometimes called the “open-closed principle in action” because it lets you add new operations (open for extension) without modifying existing classes (closed for modification).<\/li>\n <\/ul>\n<\/div>\n\n\n\nConclusion<\/strong><\/h2>\n\n\n\nThe Visitor Method Design Pattern gives you a clean way to add new operations to a group of objects without touching those objects. The objects stay focused on what they are. All new behaviour lives in separate Visitor classes that you can add, remove, or swap freely.<\/p>\n\n\n\n
The pattern has four parts: the Visitor interface, the Concrete Visitors that implement operations, the Elements that accept visitors, and the Client that connects them. Once you understand those four parts, the Visitor Method Design Pattern becomes one of the clearest ways to extend a system without breaking what already works.<\/p>\n\n\n\n
Start with the tax inspector example. Then try adding your own visitor to the shopping cart. The pattern becomes natural very quickly.<\/p>\n\n\n\n
FAQs<\/strong><\/h2>\n\n\n\n
\n
\n
1. What is double dispatch in the Visitor Method Design Pattern?<\/strong><\/h3>\n\n\n
Double dispatch means the right method is chosen based on two types: the visitor type and the element type. When an element calls visitor.visit_house(self)<\/strong>, the language picks the method based on both the visitor class and the fact that self<\/strong> is a House. This is how the Visitor Method Design Pattern routes each element to the correct logic automatically.<\/p>\n\n<\/div>\n<\/div>\n\n
2. What is the difference between Visitor and Strategy patterns?<\/strong><\/h3>\n\n\n
Strategy swaps one algorithm for another on the same object. Visitor applies different logic to different object types in a collection. Strategy is about choosing how one thing is done. Visitor is about applying the right operation to each type in a group.<\/p>\n\n<\/div>\n<\/div>\n
\n
3. Can I use the Visitor Method Design Pattern in JavaScript?<\/strong><\/h3>\n\n\n
Yes. Create a Visitor object with one method per element type. Each element class has an accept(visitor)<\/strong> method that calls the right visitor method and passes itself. The pattern works the same in JavaScript, TypeScript, Java, and C#.<\/p>\n\n<\/div>\n<\/div>\n\n
4. Is the Visitor pattern difficult to implement?<\/strong><\/h3>\n\n\n
No. The hardest part to understand is the accept()<\/strong> method. Once you see that it just calls visitor.visit_this_type(self)<\/strong>, everything else follows naturally. The tax calculator and shopping cart examples in this guide are under 30 lines each.<\/p>\n\n<\/div>\n<\/div>\n\n
5. What happens when I add a new element type?<\/strong><\/h3>\n\n\n
Every existing Visitor class must add a new visit method for the new type. This is the main trade-off of the Visitor Method Design Pattern. It is easy to add new operations but harder to add new element types. This is why the pattern works best when your element types are stable.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"
Imagine a tax inspector who visits different types of properties: houses, shops, and factories. Each property type is taxed differently. The inspector does not change the properties. The properties do not change either. The inspector simply visits each one and applies the right calculation based on what it is. That is the Visitor Method Design […]<\/p>\n","protected":false},"author":65,"featured_media":110508,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[959],"tags":[],"views":"32","authorinfo":{"name":"Jebasta","url":"https:\/\/www.guvi.in\/blog\/author\/jebasta\/"},"thumbnailURL":"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2026\/05\/Visitor-Method-Design-Pattern-300x115.webp","jetpack_featured_media_url":"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2026\/05\/Visitor-Method-Design-Pattern-scaled.webp","_links":{"self":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/110328"}],"collection":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/users\/65"}],"replies":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/comments?post=110328"}],"version-history":[{"count":3,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/110328\/revisions"}],"predecessor-version":[{"id":110511,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/110328\/revisions\/110511"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media\/110508"}],"wp:attachment":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media?parent=110328"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/categories?post=110328"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/tags?post=110328"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}