visitor-pattern

When we have an object hierarchy that is purely a inheritance of semantic and not of behaviors,then inevitably we need to write "instanceof" or "if/else" everywhere to do run time type checking. E.g. If I have a object hierarchy which has Class Function Class Average extends Function Class Sum extends Function Class Max extends Function If there is a method called calculate() in these classes, then we do not have problem, we can just take the advantage of polymorphism and this design satisfies the LSP. However what if we do not want to add this calculate() method to this hierarchy for some

I have an implementation of a State Pattern where each state handles events it gets from a event queue. Base State class therefore has a pure virtual method void handleEvent(const Event*) . Events inherit base Event class but each event contains its data that can be of a different type (e.g. int, string...or whatever). handleEvent has to determine the runtime type of the received event and then perform downcast in order to extract event data. Events are dynamically created and stored in a queue (so upcasting takes place here...). I know that downcasting is a sign of a bad design but is it

I'm new in this pattern , could please someone help me in it? I got an Object like this : public class Object { public string Name { get; set; } public object Value { get; set; } public List<Object> Childs { get; set; } } Here is an JSON example: { "Name": "Method", "Value": "And", "Childs": [{ "Name": "Method", "Value": "And", "Childs": [{ "Name": "Operator", "Value": "IsEqual", "Childs": [{ "Name": "Name", "Value": "5", "Childs": [] }] }, { "Name": "Operator", "Value": "IsEqual", "Childs": [{ "Name": "Name", "Value": "6", "Childs": [] }] }] }, { "Name": "Operator", "Value": "IsEqual",

Is it generally acceptable to allow a Visitor to modify state of the Receiver, or should that be a Command pattern instead? The purpose of the visitor pattern is to allow new operations to be added to a class heirarchy without modification to that heirarchy. I've never seen anyone suggesting that only read-only operations are acceptable. The only limitation is that the added operations should only use the public interface of the class heirarchy. I don't think you can make a blanket statement whether it's good or bad to modify state of anything. I would think it's ok to modify the states as

Here is a problem statement: We have interfaces/super classes Student and Teacher Student has two implementations/sub clasees, ScienceStudent and PhysicalEducationStudent Teacher has ScienceTeacher and PhysicalEducationTeacher. We want to implement a method getMeetingPoint(Student s, Teacher t) which returns a place where they meet based on the type of Student and Teacher. For example, if its a ScienceStudent and ScienceTeacher they meet at Lab if PEStudent and PETeacher they meet on the Ground and if its a ScienceStudent and PETeacher or vice versa, they meet at cafeteria We can write a naive

I thought it would be a simple exercise to write a generic visitor base class template. The goal is to be able to write typedef visitor<some_base, some_derived1, some_derived2> my_visitor; ...and then have my_visitor be a type that is functionally equivalent to struct my_visitor { virtual void visit(some_base&) {} virtual void visit(some_derived1&) {} virtual void visit(some_derived2&) {} }; which i can inherit with actually useful derived visitor classes for that type hierarchy, which override the different visit() versions as needed. I want it to work for any number of types having any

I have been searching around for days to find an answer to this performance based issue. After digging the Internet so far I have learned that there are couple of ways to use the Enums in java, well documented in here . Well, definitely as a starter one would like use Enums in a switch-case statement, which provides clarity and better understanding of the code. But on the other hand we have a Visitor pattern style implementation of the Enums as well, which ensures type safety and extensibility, Discussed here . Having said that, and coming back to original idea behind this question, so far I

One of the reasons to consider the Visitor_pattern : A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. Assume that you don't have the source code of third party libraries and you have added one operation on related objects. Since you don't have object, your elements (Third party classes) can't be modified to add Visitor. In this case, double dispatch is not possible. So which option is generally preferred? Option 1: Extend one more inheritance hierarchy on top of third party class and implement pattern