if else의 javascript 대소문자를 abstraction_javascript 기술로 전환합니다.

내 대답은 2개 이상의 다른 경우가 있거나 2개 이상의 사례로 전환하는 경우입니다. 하지만 코드에서 if else를 사용하고 대/소문자를 바꾸는 것은 일반적입니다. 그렇죠? 잘못된! 대부분의 if else 및 2개 이상의 분기가 있는 스위치 케이스는 하드 코딩하면 안 됩니다.
복잡한 브랜치는 어디에서 오는가?
우선, 우리가 논의하고 싶은 첫 번째 질문은 레거시 코드에 복잡한 브랜치가 왜 그렇게 많은지입니다. 이러한 복잡한 분기는 코드의 첫 번째 버전에는 존재하지 않는 경우가 많습니다. 디자이너가 아직 어느 정도 경험이 있다고 가정하면 향후 확장해야 할 영역을 예측하고 추상 인터페이스를 예약해야 합니다.

그러나 코드가 여러 번 반복된 후, 특히 요구 사항 세부 사항을 여러 번 조정한 후에는 복잡한 분기가 나타납니다. 요구 사항에 대한 자세한 조정은 UML에 반영되지 않고 코드에 직접 반영되는 경우가 많습니다. 예를 들어 메시지는 원래 채팅 메시지와 시스템 메시지라는 두 가지 범주로 나뉘었지만 설계 과정에서 자연스럽게 메시지 범주의 두 가지 하위 범주로 설계되었습니다. 그런데 어느 날 요구 사항이 세부적으로 조정되었습니다. 일부 시스템 메시지는 중요하며 해당 제목이 빨간색으로 표시되어야 합니다. 이때 프로그래머는 종종 다음과 같이 수정합니다.
시스템 메시지 클래스에 중요한 속성을 추가합니다.
제목 색상을 제어하기 위해 해당 렌더 메소드에 중요한 속성에 대한 브랜치를 추가하세요
프로그래머는 왜 이렇게 변경했을까요? 어쩌면 그것이 추상적이어야 한다는 것을 깨닫지 못했기 때문일 수도 있다. 요구 사항에 "일부 시스템 메시지가 중요하다"고 명시되어 있기 때문에 명령형 프로그래밍 언어에 대해 더 많은 교육을 받은 프로그래머의 경우 가장 먼저 생각할 수 있는 것은 플래그 비트입니다. 플래그 비트는 중요한 메시지와 중요하지 않은 메시지를 구별할 수 있습니다. . 중요한. 그는 이 요구 사항이 다른 방식으로 해석될 수 있을 것이라고는 예상하지 못했습니다. "시스템 메시지는 중요함과 중요하지 않음이라는 두 가지 범주로 나뉩니다." 이런 식으로 해석함으로써 그는 시스템 메시지가 추상화되어야 한다는 것을 알았습니다.
물론 프로그래머가 추상화가 가능하다는 것을 알고 있지만 어떤 이유로 그렇게 하지 않기로 선택할 수도 있습니다. 매우 일반적인 상황은 누군가가 프로그래머에게 프로젝트 진행 대신 코드 품질을 희생하도록 강요하는 것입니다. 속성과 분기를 추가하는 것이 추상 리팩토링보다 훨씬 간단합니다. 이 양식 수정을 10개 만드는 것이 더 빠릅니다. 아니면 10개의 추상화? 차이점은 분명합니다.
물론 if else가 너무 많으면 일부 똑똑한 사람들이 일어나 "대소문자를 바꾸는 게 어때?"라고 말할 것입니다. 어떤 경우에는 각 분기가 상호 배타적이라고 가정하면 실제로 코드 가독성이 향상될 수 있습니다. 그러나 스위치 케이스 수가 증가하면 코드도 읽을 수 없게 됩니다.
복합 브랜치의 단점은 무엇인가요
복합 브랜치의 단점은 무엇인가요? Baidu Hi 웹 버전의 이전 코드 섹션을 예로 들어 보겠습니다.

코드 복사 코드는 다음과 같습니다.

switch(json.result) {
case " ok":
switch (json.command) {
case "message":
case "systemmessage":
if (json.content.from == ""
&& json.content .content == "킥됨") {
/* 연결 끊기 */
} else if (json.command == "systemmessage"
|| json.content.type == "sysmsg" ) {
/* 시스템 메시지 렌더링 */
} else {
/* 채팅 메시지 렌더링 */
}
break
}
break; 🎜>
이 코드는 이해하기 어렵지 않으므로 어떤 브랜치가 다음 JSON 히트를 수행하는지 간단한 질문을 합니다.

코드 복사 코드는 다음과 같습니다:

{

"result": "ok",
"command": "message",
"content": {
"from" : "CatChen",
"content": "Hello!"
}
}


정답을 쉽게 얻을 수 있습니다. 이 JSON 히트 /* 채팅 메시지 렌더링 */ (채팅 메시지 표시) 이 분기입니다. 그럼 어떻게 이런 판단을 내리셨는지 알고 싶습니다. 먼저, "ok": 분기에 도달했는지 확인해야 하며 결과는 히트입니다. 그런 다음 "message": 분기에 도달하는지 확인해야 하며 결과도 히트입니다. "systemmessage"의 경우를 볼 필요가 없습니다. 다음으로, if의 조건에 맞지 않고 else if의 조건에 맞지 않으므로 else 분기에 도달합니다.

문제가 보이나요? 다른 것을 보고 이 JSON이 이 분기에 도달한다고 말할 수 없는 이유는 무엇입니까? else 자체에는 조건이 포함되어 있지 않기 때문에 조건만 암시합니다! else의 조건은 부정의 결과이고 그 앞의 if와 else if에 대한 AND 연산의 결과입니다. 즉, this else의 적중 여부를 판단하는 것은 적중 여부를 판단하기 위한 복잡한 조건 세트와 동일합니다.

코드 복사 코드는 다음과 같습니다.

!(json.content.from == "" && json.content.content == "kicked") && !(json.command == "systemmessage" || json.content.type == " sysmsg")

바깥쪽 스위치 케이스 2개를 씌웁니다. 이 브랜치의 조건은 다음과 같습니다.

코드 복사 코드는 다음과 같습니다.

json.result == "ok" && (json.command == "message" || json.command == "systemmessage") && !(json.content.from == "" && json.content.content == "킥됨") && !(json.command == "systemmessage" || json.content.type == "sysmsg")

여기서 반복되는 논리가 있습니다. 생략하면 다음과 같습니다.

코드 복사 코드는 다음과 같습니다. 다음과 같습니다:

json.result == "ok" && json.command == "message" && !(json.content.from == "" && json.content.content == " kicked") && ! (json.content.type == "sysmsg")

단순한 else 네 글자에서 이렇게 긴 일련의 논리 연산식을 도출하기 위해 얼마나 많은 노력을 기울였습니까? 게다가 주의깊게 보지 않으면 이 표현이 무엇을 말하는지 전혀 이해할 수 없습니다.
여기서 복잡한 브랜치를 읽고 관리하기가 어려워집니다. if else가 포함된 스위치 케이스가 있다고 가정해 보세요. 총 3개의 케이스가 있고 각 케이스에는 3개의 else가 있습니다. 이는 학습하기에 충분합니다. 각 분기와 조건에는 분기와 이전 분기가 모두 포함되어 있습니다. 모든 조상 브랜치는 then이 아닌 AND의 결과입니다.
복잡한 분기를 피하는 방법
우선 복잡한 논리연산은 피할 수 없습니다. 리팩토링의 결과는 동일한 논리여야 합니다. 우리가 할 수 있는 일은 코드를 더 쉽게 읽고 관리할 수 있도록 만드는 것뿐입니다. 따라서 우리는 복잡한 논리 연산을 쉽게 읽고 관리할 수 있도록 하는 방법에 중점을 두어야 합니다.
클래스 또는 팩토리로 추상화
객체 지향 설계에 익숙한 사람들에게 이는 복잡한 논리 연산을 분리하여 여러 클래스로 배포하는 것을 의미할 수 있습니다.

코드 복사 코드는 다음과 같습니다.

switch (json.result) {
case "ok":
var Factory = commandFactories .getFactory(json.command);
var command = Factory.buildCommand(json);
command.execute()
break; 보기에는 좋아 보이지만 최소한 가지가 더 짧고 코드를 읽기가 더 쉽습니다. 이 스위치 케이스는 상태 코드 분기만 처리합니다. "ok" 상태 코드를 처리하는 방법은 다른 클래스의 문제입니다. getFactory 내부에는 이 명령어가 선택해야 하는 팩토리를 선택하는 데 초점을 맞춘 일련의 분기가 있을 수 있습니다. 동시에 buildCommand에는 이 명령어를 빌드하는 방법을 결정하는 다른 사소한 분기가 있을 수 있습니다.
이것의 장점은 분기 간의 중첩 관계가 해제되고 각 분기가 해당 컨텍스트에서만 올바른 상태를 유지하면 된다는 것입니다. 예를 들어 getFactory는 이제 명명된 함수이므로 이 함수 내의 분기에서는 getFactory가 실제로 호출되는 컨텍스트에 주의를 기울이지 않고 getFactory라는 이름이 암시하는 계약만 구현하면 됩니다.
패턴 일치로 추상화

또 다른 방법은 이 복잡한 논리 연산을 패턴 일치로 변환하는 것입니다.




코드 복사

코드는 다음과 같습니다: Network.listen({ "result": "ok",

"command": "message",

"content": { " from": "", "content": "kicked" }
}, function(json) { /* 연결 해제 */ });
Network.listen([{
"result": " ok ",
"command": "message",
"content": { "type": "sysmsg" }
}, {
"result": "ok",
" command": "systemmessage"
}], function(json) { /* 시스템 메시지 렌더링 */ });
Network.listen({
"result": "ok",
" command": "message",
"content": { "from$ne": "", "type$ne": "sysmsg" }
}, func　tion(json) { /* 채팅 메시지 렌더링 */ })


이제 좀 더 명확해졌나요? 첫 번째 경우는 오프라인으로 추방되며 지정된 원본 및 콘텐츠 값과 일치해야 합니다. 두 번째 경우는 시스템 메시지를 표시하는 것입니다. 두 버전의 프로토콜에서 시스템 메시지가 약간 다르기 때문에 두 개의 서로 다른 JSON을 캡처해야 하며 일치하는 항목은 적중으로 간주됩니다. 세 번째 상황은 채팅 메시지를 표시하는 것입니다. 시스템 메시지와 킥오프 지침은 구 버전 프로토콜의 특수 채팅 메시지이므로 구 버전 프로토콜과 호환되기 위해서는 이 두 가지 상황을 제외해야 합니다. 채팅 메시지가 표시되므로 일치를 위해 접미사 "$ne"(같지 않음을 의미)를 사용하세요.
listen 메서드는 컨텍스트 프리이므로 각 Listen은 어떤 종류의 JSON과 일치하는지 독립적으로 선언하므로 암시적 논리가 없습니다. 예를 들어 채팅 메시지를 캡처하려면 == ""에서 명시적으로 제외하고 == "sysmsg"를 입력해야 하며, 그렇지 않은 경우 컨텍스트에서 추론할 필요가 없습니다.
패턴 일치를 사용하면 코드의 가독성과 유지 관리성을 크게 향상시킬 수 있습니다. 캡처하려는 내용은 JSON이므로 각 분기에서 캡처하려는 내용을 설명하기 위해 JSON을 사용합니다. 이는 긴 논리 연산 표현식보다 훨씬 명확합니다. 동시에 이 JSON의 모든 수정 사항은 독립적이며 한 조건을 수정해도 다른 조건에는 영향을 미치지 않습니다.
마지막으로 이러한 패턴 일치 모듈을 작성하는 방법은 이 기사의 범위를 벗어납니다.