你知道这五种好用的编程模式吗?
作者 | John Stewart
译者 | 王强
编辑 | Yonie
这篇文章中介绍了一些我在编程时使用的模式。有些模式是基于我最近在工作时所做的观察,还有一些是我这些年来从同事那里偷来的。
下面的顺序不分先后,只是一个简单的汇总。
function transformData(rawData) {
// check if no data
if (!rawData) {
return [];
}
// check for specific case
if (rawData.length == 1) {
return [];
}
// actual function code goes here
return rawData.map((item) => item);
}
我将这种模式称为“早退”,但有些人也将它称为 “保镖模式”或“保护条款”。除了命名之外,该模式的方法是首先检查无效用例并从该函数返回,否则继续到预期用例并执行函数。
我认为这种方法有一些优点,我很喜欢:
鼓励开发者考虑无效 / 边缘情况,以及处理这些情况的对策。
避免对意外用例做不必要的代码处理。
让开发者对每个用例的处理更加胸有成竹。
使用这种模式,开发者可以快速浏览功能并了解流程和执行情况,这通常遵循自上而下的模式——无效情况 - >小案例 - >预期案例
更多信息——Rik Schennink 的“保镖模式”:
http://rikschennink.nl/thoughts/the-bouncer-pattern/
// Switch
let createType = null;
switch (contentType) {
case "post":
createType = () => console.log("creating a post...");
break;
case "video":
createType = () => console.log("creating a video...");
break;
default:
createType = () => console.log('unrecognized content type');
}
createType();
// Object literal
const contentTypes = {
post: () => console.log("creating a post..."),
video: () => console.log("creatinga video..."),
default: () => console.log('unrecognized content type')
};
const createType = contentTypes[contentType] || contentTypes['default'];
createType();
接下来是摆脱 switch 语句。我经常在写各个 case 时犯错,而且常常会忘记 break。这会导致许多有趣的问题。在编写代码时,switch 语句的用途没那么大,而且有些碍事。
我更喜欢使用对象字面量,原因在于:
不必担心 case 或 break。
代码更容易阅读,可以快速了解正在发生的事情。
对象字面量很容易编写。
代码更简洁。
更多信息:
Map Shavin 的“Switch case、if else 或循环映射”:
https://medium.com/front-end-weekly/switch-case-if-else-or-a-lookup-map-a-study-case-de1c801d944
Todd Motto 的“用对象字面量代替 Switch 语句”:
https://ultimatecourses.com/blog/deprecating-the-switch-statement-for-object-literals
Chris Burgin 的“重写 JS:替换 Switch 语句”:
https://medium.com/chrisburgin/rewriting-javascript-replacing-the-switch-statement-cfff707cf045
const exampleValues = [2, 15, 8, 23, 1, 32];
const [truthyValues, falseyValues] = exampleValues.reduce((arrays, exampleValue) => {
if (exampleValue > 10) {
arrays[0].push(exampleValue);
return arrays;
}
arrays[1].push(exampleValue);
return arrays;
}, [[], []]);
这种模式其实没什么特别,我应该早点意识到它的。以前我的做法是检查一大堆对象来获得符合某种条件的所有对象,然后针对不同的条件再做一次检查。这意味着我要做两遍循环数组,但实际上做一遍就够了。
这个模式是从(https://30secondsofcode.org/#bifurcate)这里学来的。这个网站有很多干货,我建议大家都去看看。
我知道 reduce 可能不太好学,大家不是很清楚它背后发生了什么;但是如果你能熟悉它的用法,就可以利用它来构建循环数组时所需的各种数据结构。它其实应该叫 builder 的,比 reduce 这个名字更合适。
// bad
const foo = y && z;
// good
const isPostEnabled = isPost && postDateValid;
这个模式看起来挺眼熟的,我相信大家都见过这种代码。花点时间尽量取一个合适的名字吧。
这对于专业人士或教师来说是尤为重要的。变量命名应该用来帮助解释和给出代码内容的上下文。
当别人阅读你的代码时,他们应该能理解你想要解决的问题。
更多信息——Richard Tan 的“命名变量的艺术”:
https://hackernoon.com/the-art-of-naming-variables-52f44de00aad
let result = null;
if (conditionA) {
if (conditionB) {
result = "A & B";
} else {
result = "A";
}
} else {
result = "Not A";
}
const result = !conditionA
? "Not A"
: conditionB
? "A & B"
: "A";
我承认,嵌套三元组这个想法一开始会令人反感。它似乎是一种编写条件的好方法。然后我开始编写业务逻辑,发现自己到处在用嵌套的 if else 子句和一些非常有问题的条件逻辑。
我认为 if 和 else 作为单词更容易理解;但当它们嵌套在一起时,我就开始越来越糊涂了。
不过嵌套三元组用的多了之后,我的思路也开始变得更清晰。
我认为这种模式完全取决于你和你的团队以及你的偏好。我见过有人能很好地应付两种情况,对各自的优劣都很清楚,我个人而言是用得越来越多了。
更多信息——Eric Elliot 的“嵌套三元组真棒”:
https://medium.com/javascript-scene/nested-ternaries-are-great-361bddd0f340
原文链接:
https://www.johnstewart.dev/five-programming-patterns-i-like/
点个在看少个 bug ?
关注公众号:拾黑(shiheibook)了解更多
[广告]赞助链接:
四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/
随时掌握互联网精彩
- 1 中美关系能够有一个更好的未来 4971870
- 2 维权平台现多起小米汽车退定投诉 4951808
- 3 不让烧秸秆 看守干部餐费花10多万 4844231
- 4 以新质生产力引领经济增长 4715985
- 5 威马负债超203亿 传多位高层被抓 4622495
- 6 吴磊吃绿鸡蛋食物中毒 4531852
- 7 乌军官在办公室与多名女同事热吻 4494526
- 8 餐具清洗公司为何经不住记者暗访 4334471
- 9 北京辟谣图书馆有偿招志愿者 4258383
- 10 “90后”陈翔宇升任副市长 4115831