{"id":4774,"date":"2014-03-30T15:18:34","date_gmt":"2014-03-30T15:18:34","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2014\/03\/30\/collection-of-derived-classes-with-extended-interfaces-how-to-access-derived-interface-without-dynamic-cast-collection-of-common-programming-errors\/"},"modified":"2014-03-30T15:18:34","modified_gmt":"2014-03-30T15:18:34","slug":"collection-of-derived-classes-with-extended-interfaces-how-to-access-derived-interface-without-dynamic-cast-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2014\/03\/30\/collection-of-derived-classes-with-extended-interfaces-how-to-access-derived-interface-without-dynamic-cast-collection-of-common-programming-errors\/","title":{"rendered":"Collection of derived classes with extended interfaces. How to access derived interface without dynamic cast?-Collection of common programming errors"},"content":{"rendered":"<p>The visitor pattern is a viable solution. The solution has two main participants:<\/p>\n<ul>\n<li>Elements: The distinct types with a common parent that will accept a Visitor. In this case, the Elements are <code>Cat<\/code> and <code>Dog<\/code> with the common parent being <code>Animal<\/code>.<\/li>\n<li>Visitor: The class that will visit Elements, and can invoke Element specific operations as it has a handle to the specific Element type.<\/li>\n<\/ul>\n<p>For this example, begin with the elements (Animal, Cat, and Dog):<\/p>\n<pre><code>class Animal\n{\npublic:\n  virtual ~Animal() {}\n  virtual void eat() = 0;\n};\n\nclass Cat: public Animal\n{\npublic:\n  void destroyFurniture();\n  void eat(); \n};\n\nclass Dog: public Animal\n{\npublic:\n  void chaseTail();\n  void eat();\n};\n<\/code><\/pre>\n<p>Next, create a Visitor that will &#8216;visit&#8217; each Element. The Visitor will know the type it is operating on, so it can use methods on both the specific Elements, such as <code>Cat::destroyFurniture()<\/code> and <code>Dog::chaseTail()<\/code>:<\/p>\n<pre><code>class Visitor\n{\npublic:\n   void visitDog( Dog&amp; dog ) { dog.chaseTail();        }\n   void visitCat( Cat&amp; cat ) { cat.destroyFurniture(); }\n};\n<\/code><\/pre>\n<p>Now, add a pure virtual method to <code>Animal<\/code> that accepts a <code>Visitor<\/code> as an argument: <code>void Animal::accept( Vistor&amp; )<\/code>. The idea is to pass a <code>Visitor<\/code> to an <code>Animal<\/code>, and allow the virtual method to resolve to the specific runtime type. Once the virtual call is resolved, the implementation can invoke the specific <code>visit<\/code> method on the <code>Visitor<\/code>.<\/p>\n<pre><code>class Animal\n{\npublic:\n  ...\n  virtual void accept( Visitor&amp; ) = 0;\n};\n\nclass Cat: public Animal\n{\npublic:\n  ...\n  virtual void accept( Visitor&amp; visitor ) { visitor.visitCat( *this ); }\n};\n<\/code><\/pre>\n<p>Notice how the virtual method is used to resolve to the specific Element type, and that that each element&#8217;s <code>accept<\/code> implementation will invoke a method on the Visitor. This allows for execution to branch based on type without the use of <code>dynamic_cast<\/code>, and is commonly referred to as double dispatch.<\/p>\n<p>Here is a compilable example that demonstrates the pattern in use:<\/p>\n<pre><code>#include \n#include \n\nusing std::cout;\nusing std::endl;\n\nclass Cat;\nclass Dog;\n\nclass Visitor\n{\npublic:\n   void visitCat( Cat&amp; cat );\n   void visitDog( Dog&amp; dog );\n};\n\nclass Animal\n{\npublic:\n  virtual ~Animal() {}\n  virtual void eat() = 0;\n  virtual void accept( Visitor&amp; ) = 0;\n};\n\nclass Cat: public Animal\n{\npublic:\n  void destroyFurniture()         { cout<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"<p>The visitor pattern is a viable solution. The solution has two main participants: Elements: The distinct types with a common parent that will accept a Visitor. In this case, the Elements are Cat and Dog with the common parent being Animal. Visitor: The class that will visit Elements, and can invoke Element specific operations as [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4774","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/4774","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=4774"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/4774\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=4774"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=4774"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=4774"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}