Is there an objectively preferrable reason to use events over a switch statement?What is the best way to generate a login token? Is this method of authentication vulnerable to attack?Iterate over object keys in node.jsA proper approach to FB authIs a new function defined for every socket in Socket.IO?Socket.IO with multipul tabs of browserMongoose connection sockets closedConnect second time socket.ioOpening non-default browser with lite-server in angular2 quick start guideRun Windows Node.js script in background when the user logins by setting a Run keyJWT Authentication system in webpage using nodejs
Multi tool use
Initialize an std::array algorithmically at compile time
Accidentally renamed tar.gz file to a non tar.gz file, will my file be messed up
Why don't B747s start takeoffs with full throttle?
Metal bar on DMM PCB
Will TSA allow me to carry a Continuous Positive Airway Pressure (CPAP) device?
Old black and white movie: glowing black rocks slowly turn you into stone upon touch
How certain is a caster of when their spell will end?
Do I include animal companions when calculating difficulty of an encounter?
How can Iron Man's suit withstand this?
What is the history of the check mark / tick mark?
X-shaped crossword
What is the right way to float a home lab?
The ring of global sections of a regular scheme
Is it a problem that pull requests are approved without any comments
Applicants clearly not having the skills they advertise
Is it OK to bring delicacies from hometown as tokens of gratitude for an out-of-town interview?
Why does a helium balloon rise?
Chopin: marche funèbre bar 15 impossible place
Count line of code for Javascript project
Is there any rule preventing me from starting multiple bardic performances in a single round?
What do we gain with higher order logics?
Short story written from alien perspective with this line: "It's too bright to look at, so they don't"
The term for the person/group a political party aligns themselves with to appear concerned about the general public
Who operates delivery flights for commercial airlines?
Is there an objectively preferrable reason to use events over a switch statement?
What is the best way to generate a login token? Is this method of authentication vulnerable to attack?Iterate over object keys in node.jsA proper approach to FB authIs a new function defined for every socket in Socket.IO?Socket.IO with multipul tabs of browserMongoose connection sockets closedConnect second time socket.ioOpening non-default browser with lite-server in angular2 quick start guideRun Windows Node.js script in background when the user logins by setting a Run keyJWT Authentication system in webpage using nodejs
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I'll clarify my question by first describing my use case:
I am writing an IMAP server, which receives commands from clients. If it is in the right state to do so, it reads a token from the network socket, and interprets that token as a command's name. As of right now, my server reads the command's name from the token and uses a switch
statement to execute the corresponding code.
Here's a glimpse of it:
case ("CAPABILITY"): this.executeCapability(tag); break;
case ("NOOP"): this.executeNoop(tag); break;
case ("LOGOUT"): this.executeLogout(tag); break;
case ("LOGIN"): this.executeLogin(tag, args); break;
My question is: is there an objectively preferable reason to use events to dispatch commands instead? Would performance be better? Is there a security advantage?
My proposed alternative might look something like this:
server.on("CAPABILITY", executeCapability);
server.on("NOOP", executeNoop);
server.on("LOGOUT", executeLogout);
server.on("LOGIN", executeLogin);
node.js
add a comment |
I'll clarify my question by first describing my use case:
I am writing an IMAP server, which receives commands from clients. If it is in the right state to do so, it reads a token from the network socket, and interprets that token as a command's name. As of right now, my server reads the command's name from the token and uses a switch
statement to execute the corresponding code.
Here's a glimpse of it:
case ("CAPABILITY"): this.executeCapability(tag); break;
case ("NOOP"): this.executeNoop(tag); break;
case ("LOGOUT"): this.executeLogout(tag); break;
case ("LOGIN"): this.executeLogin(tag, args); break;
My question is: is there an objectively preferable reason to use events to dispatch commands instead? Would performance be better? Is there a security advantage?
My proposed alternative might look something like this:
server.on("CAPABILITY", executeCapability);
server.on("NOOP", executeNoop);
server.on("LOGOUT", executeLogout);
server.on("LOGIN", executeLogin);
node.js
add a comment |
I'll clarify my question by first describing my use case:
I am writing an IMAP server, which receives commands from clients. If it is in the right state to do so, it reads a token from the network socket, and interprets that token as a command's name. As of right now, my server reads the command's name from the token and uses a switch
statement to execute the corresponding code.
Here's a glimpse of it:
case ("CAPABILITY"): this.executeCapability(tag); break;
case ("NOOP"): this.executeNoop(tag); break;
case ("LOGOUT"): this.executeLogout(tag); break;
case ("LOGIN"): this.executeLogin(tag, args); break;
My question is: is there an objectively preferable reason to use events to dispatch commands instead? Would performance be better? Is there a security advantage?
My proposed alternative might look something like this:
server.on("CAPABILITY", executeCapability);
server.on("NOOP", executeNoop);
server.on("LOGOUT", executeLogout);
server.on("LOGIN", executeLogin);
node.js
I'll clarify my question by first describing my use case:
I am writing an IMAP server, which receives commands from clients. If it is in the right state to do so, it reads a token from the network socket, and interprets that token as a command's name. As of right now, my server reads the command's name from the token and uses a switch
statement to execute the corresponding code.
Here's a glimpse of it:
case ("CAPABILITY"): this.executeCapability(tag); break;
case ("NOOP"): this.executeNoop(tag); break;
case ("LOGOUT"): this.executeLogout(tag); break;
case ("LOGIN"): this.executeLogin(tag, args); break;
My question is: is there an objectively preferable reason to use events to dispatch commands instead? Would performance be better? Is there a security advantage?
My proposed alternative might look something like this:
server.on("CAPABILITY", executeCapability);
server.on("NOOP", executeNoop);
server.on("LOGOUT", executeLogout);
server.on("LOGIN", executeLogin);
node.js
node.js
asked Mar 24 at 13:24
Jonathan WilburJonathan Wilbur
14510
14510
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Events are more easily extensible and usable by other code. They live in a system where the infrastructure already exists for anyone else to listen for any of those events. If you're calling a function, passing an argument and then using a switch statement to dispatch, then that's a custom, non-standard interface and if someone else (even another part of your own code) wants to listen for one of those events and act on it themselves, then they have to build some of their own custom code to somehow do that.
If you use events, then that infrastructure is already there. They can just listen for the event with their own listener.
Here's a little example. Imagine that for performance reasons you are caching some data from the database for each user. When the user logs out, you'd like to clear the cache. Your cache system is its own module because it can be reused in other apps. If you use events, the cache can just set its own event listener for the logout event and can do its own housekeeping when a given user logs out. In the switch design, you'd probably have to insert code in the executeLogout()
function to call some method in the cache. That would work, but the code wouldn't be as encapsulated as it could be. Now, you have cache logic in the logout()
method where you wouldn't need that with the event system because the cache can just watch for the events its interested in all on its own.
I'm not saying this is a killer example that means you have to do it one way or the other. Just showing some architectural advantages of events where it allows sub-systems easier access to the events so they can manage themselves (more encapsulated code) more easily.
I don't think there would be a meaningful performance difference. If you were in a tight performance sensitive loop, the event subsystem probably introduces a few more function calls to dispatch vs. the switch statement, but for regular code this wouldn't be consequential.
That's a great point I had not even considered: modularity / encapsulation! Thank you!
– Jonathan Wilbur
Mar 24 at 15:44
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55324255%2fis-there-an-objectively-preferrable-reason-to-use-events-over-a-switch-statement%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Events are more easily extensible and usable by other code. They live in a system where the infrastructure already exists for anyone else to listen for any of those events. If you're calling a function, passing an argument and then using a switch statement to dispatch, then that's a custom, non-standard interface and if someone else (even another part of your own code) wants to listen for one of those events and act on it themselves, then they have to build some of their own custom code to somehow do that.
If you use events, then that infrastructure is already there. They can just listen for the event with their own listener.
Here's a little example. Imagine that for performance reasons you are caching some data from the database for each user. When the user logs out, you'd like to clear the cache. Your cache system is its own module because it can be reused in other apps. If you use events, the cache can just set its own event listener for the logout event and can do its own housekeeping when a given user logs out. In the switch design, you'd probably have to insert code in the executeLogout()
function to call some method in the cache. That would work, but the code wouldn't be as encapsulated as it could be. Now, you have cache logic in the logout()
method where you wouldn't need that with the event system because the cache can just watch for the events its interested in all on its own.
I'm not saying this is a killer example that means you have to do it one way or the other. Just showing some architectural advantages of events where it allows sub-systems easier access to the events so they can manage themselves (more encapsulated code) more easily.
I don't think there would be a meaningful performance difference. If you were in a tight performance sensitive loop, the event subsystem probably introduces a few more function calls to dispatch vs. the switch statement, but for regular code this wouldn't be consequential.
That's a great point I had not even considered: modularity / encapsulation! Thank you!
– Jonathan Wilbur
Mar 24 at 15:44
add a comment |
Events are more easily extensible and usable by other code. They live in a system where the infrastructure already exists for anyone else to listen for any of those events. If you're calling a function, passing an argument and then using a switch statement to dispatch, then that's a custom, non-standard interface and if someone else (even another part of your own code) wants to listen for one of those events and act on it themselves, then they have to build some of their own custom code to somehow do that.
If you use events, then that infrastructure is already there. They can just listen for the event with their own listener.
Here's a little example. Imagine that for performance reasons you are caching some data from the database for each user. When the user logs out, you'd like to clear the cache. Your cache system is its own module because it can be reused in other apps. If you use events, the cache can just set its own event listener for the logout event and can do its own housekeeping when a given user logs out. In the switch design, you'd probably have to insert code in the executeLogout()
function to call some method in the cache. That would work, but the code wouldn't be as encapsulated as it could be. Now, you have cache logic in the logout()
method where you wouldn't need that with the event system because the cache can just watch for the events its interested in all on its own.
I'm not saying this is a killer example that means you have to do it one way or the other. Just showing some architectural advantages of events where it allows sub-systems easier access to the events so they can manage themselves (more encapsulated code) more easily.
I don't think there would be a meaningful performance difference. If you were in a tight performance sensitive loop, the event subsystem probably introduces a few more function calls to dispatch vs. the switch statement, but for regular code this wouldn't be consequential.
That's a great point I had not even considered: modularity / encapsulation! Thank you!
– Jonathan Wilbur
Mar 24 at 15:44
add a comment |
Events are more easily extensible and usable by other code. They live in a system where the infrastructure already exists for anyone else to listen for any of those events. If you're calling a function, passing an argument and then using a switch statement to dispatch, then that's a custom, non-standard interface and if someone else (even another part of your own code) wants to listen for one of those events and act on it themselves, then they have to build some of their own custom code to somehow do that.
If you use events, then that infrastructure is already there. They can just listen for the event with their own listener.
Here's a little example. Imagine that for performance reasons you are caching some data from the database for each user. When the user logs out, you'd like to clear the cache. Your cache system is its own module because it can be reused in other apps. If you use events, the cache can just set its own event listener for the logout event and can do its own housekeeping when a given user logs out. In the switch design, you'd probably have to insert code in the executeLogout()
function to call some method in the cache. That would work, but the code wouldn't be as encapsulated as it could be. Now, you have cache logic in the logout()
method where you wouldn't need that with the event system because the cache can just watch for the events its interested in all on its own.
I'm not saying this is a killer example that means you have to do it one way or the other. Just showing some architectural advantages of events where it allows sub-systems easier access to the events so they can manage themselves (more encapsulated code) more easily.
I don't think there would be a meaningful performance difference. If you were in a tight performance sensitive loop, the event subsystem probably introduces a few more function calls to dispatch vs. the switch statement, but for regular code this wouldn't be consequential.
Events are more easily extensible and usable by other code. They live in a system where the infrastructure already exists for anyone else to listen for any of those events. If you're calling a function, passing an argument and then using a switch statement to dispatch, then that's a custom, non-standard interface and if someone else (even another part of your own code) wants to listen for one of those events and act on it themselves, then they have to build some of their own custom code to somehow do that.
If you use events, then that infrastructure is already there. They can just listen for the event with their own listener.
Here's a little example. Imagine that for performance reasons you are caching some data from the database for each user. When the user logs out, you'd like to clear the cache. Your cache system is its own module because it can be reused in other apps. If you use events, the cache can just set its own event listener for the logout event and can do its own housekeeping when a given user logs out. In the switch design, you'd probably have to insert code in the executeLogout()
function to call some method in the cache. That would work, but the code wouldn't be as encapsulated as it could be. Now, you have cache logic in the logout()
method where you wouldn't need that with the event system because the cache can just watch for the events its interested in all on its own.
I'm not saying this is a killer example that means you have to do it one way or the other. Just showing some architectural advantages of events where it allows sub-systems easier access to the events so they can manage themselves (more encapsulated code) more easily.
I don't think there would be a meaningful performance difference. If you were in a tight performance sensitive loop, the event subsystem probably introduces a few more function calls to dispatch vs. the switch statement, but for regular code this wouldn't be consequential.
answered Mar 24 at 15:25
jfriend00jfriend00
449k56596641
449k56596641
That's a great point I had not even considered: modularity / encapsulation! Thank you!
– Jonathan Wilbur
Mar 24 at 15:44
add a comment |
That's a great point I had not even considered: modularity / encapsulation! Thank you!
– Jonathan Wilbur
Mar 24 at 15:44
That's a great point I had not even considered: modularity / encapsulation! Thank you!
– Jonathan Wilbur
Mar 24 at 15:44
That's a great point I had not even considered: modularity / encapsulation! Thank you!
– Jonathan Wilbur
Mar 24 at 15:44
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55324255%2fis-there-an-objectively-preferrable-reason-to-use-events-over-a-switch-statement%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
d92WclspPpLG,YKa0Ge1UvMzgx J9NeLS7P9C1vG7RSSEG