函数的参数越少越好
有一个准则是:如果你的函数参数超过两个,就应该改为对象传入。
这样做是合理的,因为当函数参数超过两个时,参数顺序开始变得难以记忆,而且容易出现一种很尴尬的情况:比如我只需要传入第三个参数,因为其自身顺序的原因,不得不补齐前两个根本用不上的参数,以让它顺利排在第三位。
// bad const createArticle = (title, author, date, content) => { } createArticle('震惊,一男子竟偷偷干这事', 'zhangnan', '2020/06/29', '某天深夜,我喝多了点酒...') // good const createArticle = ({title, author, date, content}) => { } createArticle({ title: '震惊,一男子竟偷偷干这事', author: 'zhangnan', date: '2020/06/29', content: '某天深夜,我喝多了点酒...' })
保持函数的单一职责原则
这是软件开发领域亘古不变的一个真理,让一个函数只专注于一件事情,能够很好的解耦各个功能之间的联系,使得后续对某一个功能进行更改时,不用担心会影响其他模块。
假设我们现在有一个需求:现在需要给班里的每一个同学发放假短信通知,如果是男生,就用电信主机号来发,如果是女生,则用联通主机号发,同时额外发送一封爱心邮件。实现如下:
// bad 代码挤成一堆,很难理清 // 男生女生的通知方式还有所不同,后期如果要改动女生的通知方式,很难保证不会影响到男生 // 因为大家都写在同一个函数里 const notifyStudents = (studentList) => { studentList.forEach(student => { if (student.gender === 'male') { const sender1 = new SmsSender({ carrier: '电信' }); sender1.init(); sender1.sendTo(student) } else { const sender2 = new SmsSender({ carrier: '联通' }); sender2.init(); sender2.sendTo(student); const sender3 = new EmailSender({ type: 'QQ邮箱' }); sender3.connect(); sender3.sendTo(student) } }) } // good 函数拆分,各司其职,清晰明了 // 虽然看起来代码量多了一点点 // 但是分工明确,互不影响 const initSmsSender = (carrier) => { const sender = new SmsSender({ carrier }); sender.init(); } const initEmailSender = (type) => { const sender = new EmailSender({ type }); sender.connect(); } const notifyMales = (studentList) => { const smsSender = initSmsSender('电信'); const maleList = studentList.filter(student => student.gender === 'male'); maleList.forEach(male => smsSender.sendTo(male)); } const notifyFemales = (studentList) => { const smsSender = initSmsSender('联通'); const emailSender = initEmailSender('QQ邮箱'); const femaleList = studentList.filter(student => student.gender === 'female'); femaleList.forEach(female => { smsSender.sendTo(female); emailSender.sendTo(female); }) }
封装条件语句
像有一些条件语句,可能存在很多与或非逻辑,如果直接写在函数里面,每次都需要重新理一遍,费时费力。把一堆条件语句封装在一个函数里面,不仅遵循单一职责原则,也将使得阅读更加方便。
// bad const shouldIBuyThisPhone = (phone) => { const {price, year, brand} = phone; if (price > 5000 && year === new Date.getFullYear() && brand === 'huawei') { // 马上剁手 } } // good const isHuaweiFlagShipThisYear = ({ price, year, brand }) => { const HIGH_PRICE = 5000; return price > HIGH_PRICE && year === new Date.getFullYear() && brand === 'huawei' } const shouldIBuyThisPhone = (phone) => { if (isHuaweiFlagShipThisYear(phone)) { // 马上剁手 } }
高层函数不要依赖具体实现
在一些动作函数中,常见的一种情况是传一个flag参数,通过对标志变量的判断,做出不同的响应动作。
这样其实是不太好的,因为这会使这个动作函数内部去维护一些判断逻辑,如果flag参数比较多,函数内部的区分情况也会很多。
另外这里也涉及一种思想:具体的差异实现应该由使用者提供,而不是统一执行者去维护。
或者称之为依赖倒置原则:高层模块(打印)不应该依赖于实现细节(某个人的喜好)。
比如,我现在有一台打印机"htmlcode">
// bad 需要判断标志变量,同时做出不同的相应动作 const print = (person) => { if (person === 'A') { device.print({ page: 1, color: 'gray', orientation: 'landscape' }) } else if (person === 'B') { device.print({ page: 1, color: 'colorful', orientation: 'vertical' }) } else if (person === 'C') { device.print({ page: 2, color: 'colorful' , orientation: 'landscape' }) } ...... } // good const print = (config) => { device.print(config) }
写在最后
总结:
- 函数传参越少越好,多了改为对象传入
- 保持函数单一职责原则
- 封装条件语句
- 高层函数不要依赖具体实现
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
暂无评论...
更新日志
2024年11月25日
2024年11月25日
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]