If else in JavaScript differs from switch usage

In fact, the meaning of "if else" is the same as the literal meaning, that is, "if" or "otherwise". Let's take a look at an example that uses if.

If you're writing a program for a robot, the robot's function is to evaluate the user's hobby.

Robot: "What is your hobby?" ”

If it's JavaScript

Robot: "Wow, there is development." ”

Then the corresponding JavaScript should be

If else small instance one:

var a=15;
if (a==20)
{
Alert (1);
}
else if (a==10)
{
Alert (2)
}
else if (a==15)
{
Alert (3)
}
Else
{
Alert ("All not established");
}

If else small instance two:

var a=15;
if (a<20)
{
Alert (1);
}
else if (a>10)
{
Alert (2)
}
else if (a==15)
{
Alert (3)
}
Else
{
Alert ("All not established");
}

Switch Small Instance one:

var a=5;

Switch (a)
{
Case 10://Condition
Alert ("a");
Break Jump out of the loop
Case 20:
Alert ("B");
Break
Case 30:
Alert ("C");
Break
Default
Alert ("All not established");
}

What's the downside of complex branching?
What's the downside of complex branching? Let me from the Baidu Hi Web version of the old code to intercept a paragraph out to do an example.
Copy code code as follows:

Switch (json.result) {
Case "OK":
Switch (Json.command) {
Case "message":
Case "SystemMessage":
if (Json.content.from = = ""
&& Json.content.content = = "kicked") {
* Disconnect * *
else if (Json.command = "SystemMessage")
|| Json.content.type = = "Sysmsg") {
/* Render System Message * *
} else {
/* Render Chat message * *
}
Break
}
Break

This code is easy to read, so I'm going to ask you a simple question about which branch this JSON hits:
Copy code code as follows:

{
"Result": "OK",
"Command": "Message",
"Content": {
"From": "Catchen",
"Content": "Hello!"
}
}

It's easy for you to get the correct answer: this JSON hit/* Render chat message/(show chat messages) This branch. So I want to know, how did you make this judgment? First, you want to see if it hits the case "OK": the branch, the result is a hit; then you want to see if it hits the case "message": The branch, the result is also hit, so the case "SystemMessage": no need to see; Next, it does not hit the condition inside the IF; Also, it does not hit the condition in else if, so it hits the else this branch.
Can you see the problem? Why can't you just look at this else and say this JSON hit this branch? Because else itself does not contain any conditions, it only implies conditions! The condition of each else is the result of the first negation and operation of every if and else if before it. That is, judging a hit on this else is equivalent to judging a set of complex conditions for a hit:
Copy code code as follows:

! (Json.content.from = = "" && json.content.content = = "kicked") &&! (Json.command = = "SystemMessage" | | | json.content.type = "SYSMSG")

Then set up the outer two switch case, the condition of this branch is this:
Copy code code as follows:

Json.result = = "OK" && (Json.command = = "message" | | json.command = = "SystemMessage") &&! (Json.content.from = = "" && json.content.content = = "kicked") &&! (Json.command = = "SystemMessage" | | | json.content.type = "SYSMSG")

There is a repetition logic in this, which is omitted as follows:
Copy code code as follows:

Json.result = = "OK" && Json.command = = "Message" &&! (Json.content.from = = "" && json.content.content = = "kicked") &&! (Json.content.type = = "Sysmsg")

How much effort did we take to derive such a long string of logical expressions from the simple else four letters? Moreover, does not look closely also really does not understand this expression to say is what.
This is where complex branches are difficult to read and manage. Imagine you face a switch case set an if else, there are a total of 3 case, each case has 3 else, which is enough for you to study--each branch, the condition implies that all of its predecessor branches and all ancestor branches of the predecessor branch first and then the results.
How to avoid complex branches
First, complex logic operations cannot be avoided. The results of refactoring should be equivalent logic, and all we can do is make the code easier to read and manage. Therefore, our focus should be on how to make complex logic operations easier to read and manage.
Abstract as a class or factory
For those accustomed to doing object-oriented design, this may mean breaking and distributing complex logic operations into different classes:
Copy code code as follows:

Switch (json.result) {
Case "OK":
var factory = commandfactories.getfactory (Json.command);
var command = Factory.buildcommand (JSON);
Command.Execute ();
Break
}

This looks good, at least the branches are getting shorter, and the code becomes easier to read. This switch case just the status Code branch, for "OK" This status code specific how to deal with, that is the other kind of things. GetFactory may have a set of branches that focus on the choice of which factory should be chosen to create this instruction. At the same time Buildcommand may have other trivial branches that decide how to build this instruction.
The advantage of this is that nested relationships between branches are lifted, and each branch is as good as it is in its own context. For example, GetFactory is now a named function, so the branch within this function can only implement the contract implied by the name GetFactory, without paying attention to the context in which getfactory is actually invoked.
Abstract for pattern matching
Another approach is to relay this complex logic operation to pattern matching:
Copy code code as follows:

Network.listen ({
"Result": "OK",
"Command": "Message",
"Content": {"from": "", "content": "Kicked"}
}, function (JSON) {/* disconnect */});
Network.listen ([{
"Result": "OK",
"Command": "Message",
' content ': {' type ': ' Sysmsg '}
}, {
"Result": "OK",
"Command": "SystemMessage"
], function (JSON) {/* Render system Message */});
Network.listen ({
"Result": "OK",
"Command": "Message",
"Content": {"From$ne": "", "Type$ne": "Sysmsg"}
}, func tion (JSON) {/* Render chat message */});

Is this so much clearer now? In the first case, it is kicked off the line and must match the specified from and content values. The second scenario is to display system messages, because system messages are slightly different in two versions of the protocol, so we're going to capture two different JSON matches, whichever is hit. The third scenario is to display chat messages, because the system message and the boot line instruction in the old version agreement belong to the special chat message, in order to be compatible with the old version protocol, these two cases should be excluded from the display chat message, so the suffix of "$ne" (representing not equal) is used to match.
Because the Listen method is context-independent, each listen declares itself to match what JSON is, so there is no implied logic. For example, to capture chat messages, you must explicitly declare exclude from = = "" and type = = "Sysmsg", which do not need to be inferred from the context if else.
using pattern matching can greatly improve the readability and maintainability of your code. Since we're capturing JSON, we use JSON to describe what each branch is capturing, which is much clearer than a long logical expression. At the same time, every modification on this JSON is independent, and modifying one condition does not affect other conditions.