You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With how the visitor pattern is currently represented here I honestly don't see the benefits of this pattern used properly. Basically it doesn't offer anything over this:
functionvisit(e,callback){if(einstanceofOperation){returncallback(e)}thrownewTypeError('not an Operation')}
The current version would work in languages with static typing since you can have multiple overloads of the identically named visit methods, but in javascript this is not possible.
So what I'd recommend instead is this:
classOperation{accept(visitor){thrownewError('You should really implement this')}}classSumextendsOperation{accept(visitor){returnvisitor.visitSum(this)}}classMinextendsOperation{accept(visitor){returnvisitor.visitMin(this)}}// ...
This way in your visitor you can properly distinguish (and in a way are forced to) all the subclasses.
Now a more javascript-idiomatic way (in my opinion at least) would be to have something like this:
classOperation{/*...*/}classSumextendsOperation{/*...*/}classMinextendsOperation{/*...*/}classNumextendsOperation{/*...*/}constcreateVisitor=(config={})=>(input, ...args)=>{constmethod=inputinstanceofOperation
? config[input.constructor.name]||config.Any||(()=>{})
: config.Unknown||(()=>{})returnmethod.call(config,input, ...args)}constvisitor=createVisitor({Sum(sum){return"It's a Sum"},Min(min){return"It's a Min"},Any(op){return"I don't care what it is, but it's an Operation"},Unknown(alien){thrownewError("I don't know what it is")}})expect(visitor(newSum())).toBe("It's a Sum")expect(visitor(newMin())).toBe("It's a Min")expect(visitor(newNum())).toBe("I don't care what it is, but it's an Operation")expect(visitor(newOperation())).toBe("I don't care what it is, but it's an Operation")expect(()=>visitor(null)).toThrowError("I don't know what it is")
This is very far from the traditional visitor pattern, but achieves the same thing.
The text was updated successfully, but these errors were encountered:
I actually recreate the visitor example, it was totally out of context.
I'll close it by now, but feel free to create a pull request if you think you can improve the new version somehow.
With how the visitor pattern is currently represented here I honestly don't see the benefits of this pattern used properly. Basically it doesn't offer anything over this:
The current version would work in languages with static typing since you can have multiple overloads of the identically named
visit
methods, but in javascript this is not possible.So what I'd recommend instead is this:
This way in your visitor you can properly distinguish (and in a way are forced to) all the subclasses.
Now a more javascript-idiomatic way (in my opinion at least) would be to have something like this:
This is very far from the traditional visitor pattern, but achieves the same thing.
The text was updated successfully, but these errors were encountered: