代码整洁之道——3、对象和数据结构

一、使用getters和setters

使用getters和setters获取对象数据比简单查找对象属性要好。因为:

1、当你想要做的不仅仅是获取对象属性,你不必查找和修改你代码中的每处访问。

2、使用set可以使验证变简单。

3、封装内部结构。

4、使用get和set,容易打日志和处理错误。

5、比如从服务器获取,你可以延迟加载你的对象属性(?)

Bad:
function makeBankAccount() {
  // ...

  return {
    balance: 0,
    // ...
  };
}

const account = makeBankAccount();
account.balance = 100;

Good:
function makeBankAccount() {
  // 这是一个私有属性
  let balance = 0;

  // a "getter", 通过返回值使这个属性变成共有属性
  function getBalance() {
    return balance;
  }

  // a "setter", 通过返回值使这个属性变成共有属性
  function setBalance(amount) {
    // 在更新前验证
    balance = amount;
  }

  return {
    // ...
    getBalance,
    setBalance,
  };
}

const account = makeBankAccount();
account.setBalance(100);

二、让对象有私有成员

这个可以通过闭包来实现(ES5及以下版本)

Bad:
const Employee = function(name) {
  this.name = name;
};

Employee.prototype.getName = function getName() {
  return this.name;
};

const employee = new Employee(‘John Doe‘);
console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe
delete employee.name;
console.log(`Employee name: ${employee.getName()}`); // Employee name: undefined

Good:
function makeEmployee(name) {
  return {
    getName() {
      return name;
    },
  };
}

const employee = makeEmployee(‘John Doe‘);
console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe
delete employee.name;
console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe
时间: 2024-10-14 23:59:01

代码整洁之道——3、对象和数据结构的相关文章

《代码整洁之道》读后感

众所周知,软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关.这一点,无论是敏捷开发派还是传统开发派,都不得不承认.<代码整洁之道>提出一种观念:代码质量与其整洁度成正比.干净的代码,既在质量上较为可靠,也为后期维护.升级奠定了良好的基础.作为编程领域的佼佼者,这些实践在<代码整洁之道>中体现为一条条规则(或称“启示”),并辅以来自现实项目的正.反两面的范例.只要遵循这些规则,就能编写出干净的代码,从而有效提升代码质量.以上便是<代码整洁之道>这本书的内容简介,

&lt;代码整洁之道&gt;、&lt;java与模式&gt;、&lt;head first设计模式&gt;读书笔记集合

一.前言                                                                                       几个月前的看书笔记,内容全部都是摘自书中比较精辟的句子.笔记都是一段一段的句子,故没有文章的篇幅概念,仅供温习之用,更多详细内容请看原书!!! <代码整洁之道>里面有很多前人编写简洁.漂亮代码的经验.当然书中作者的经验并不100%适合每个人,但大部分都是可借鉴的! <java与模式>这本书内容太多了,我

【读书笔记】--代码整洁之道

“相对于任何宏伟景愿,对细节的关注甚至是更为关键的专业性基础.首先,开发者通过小型实践获得可用于大型实践的技能和信用度.其次,宏伟建筑中最细小的部分,比如关不紧的门,有点儿没有铺平的地板,甚至是凌乱的桌面,都会将整个大局的魅力毁灭殆尽.这就是整洁代码之所系”----没有比书中的这段话更能说明这本书的意义了. <代码整洁之道>是第1期书山有路活动选出的读本.相对于记住那些如何写出整洁代码的那些法则,养成保持代码整洁.提高代码质量的习惯和思维更为重要.全书大致分为三个部分,第一部分1-10章都是介

代码整洁之道

命名,多花些时间推敲命名, 有意义的命名非常重要. 接口的命名,不使用"I"开头比较简洁,加上I以后是比较规范,但是比较繁琐以及废话.如果想区别接口和实现,不如在实现类中进行编码,比如添加后缀"Imp",android以及jdk中的大多数接口都没有使用I. 取名字带有简写要慎重, 比如"人事系统"的类, 前面都是"RSXT..",除了让快捷按钮找不到类以外,没有啥意义了,用包吧. 函数,函数要短小,要职责明确,最好功能单一,参

《代码整洁之道》学习笔记

这几天读了<代码整洁之道>的前面10个章节,收益颇多.此书结合代码,直接对比代码修改前和修改后的效果,可以让读者立刻看到修改的效果.回头看看自己写过的代码,果然里面存在不少书中指出的问题,比如变量命名随意.类过大.函数过大等等.现在我在此对书中给我深刻印象的部分做些整理,以备以后查看. 首先就是命名,包括变量.函数.类等.我在构建代码时,常常由于难以想出怎么用英文来表达一个词,而用中文拼音又显得太low.我高兴的时候就百度下单词,这样的命名还算可以:没心思的时候就各种随意的名字出来了,后面看到

2015年第11本:代码整洁之道Clean Code

前一段时间一直在看英文小说,在读到<Before I fall>这本书时,读了40%多实在看不下去了,受不了美国人啰啰嗦嗦的写作风格,还是读IT专业书吧. 从5月9日开始看<代码整洁之道>,5月14日完成第一遍的阅读(略掉了并发编程的章节以及两大章重要的JAVA改进的示例),本书中包含大量的有关简洁代码的实用性建议,强烈推荐程序员们(想成为更好的程序员们)必读此书.书中有许多具体的例子,虽然大多是JAVA代码,但对.NET等编程语言同样适用.看完此书后,马上开始对自己手头的代码进行

《代码整洁之道》

代码整洁之道 代码猴子(Code Monkey): 低水平编码者. 童子军规. 技艺(craftsmanship): 知和行. 学写整洁代码, 掌握原则和模式, 并付出行动. 整洁代码 代码呈现了需求的细节. 这些细节无法被忽略或抽象, 必须要严谨, 精确, 规范和详细. 糟糕的代码 糟糕的代码可能毁掉一家公司. 稍后等于永不(Later equals never). 随着混乱的增加, 团队生产力也持续下降,最后将趋向于零. 花时间保持代码整洁不但有关效率, 还有关生存. 代码整洁的程序员就像是

&lt;读书笔记&gt; 代码整洁之道

概述 1.本文档的内容主要来源于书籍<代码整洁之道>作者Robert C.Martin,属于读书笔记. 2.软件质量,不仅依赖于架构和项目管理,而且与代码质量紧密相关,本书提出一种,代码质量与整洁成正比的观点,并给出了一系列行之有效的整洁代码操作实践,只要遵循这些规则,就可以编写出整洁的代码,从而提升代码质量. 3.该书介绍的规则均来自于作者多年的实践经验,涵盖从命名到重构的多个编程方面,具有很好的学习和借鉴价值. 4.习艺要有二:知和行.你应当学习有关规则.模式和实践的知识,穷尽应知之事,并

代码整洁之道读后感(二)

有意义的命名和函数 命名: 名副其实---选个好名字要花很长时间,但省下来的时间更多.如果发现有更好的名称,就换掉旧的. 避免误导---比如,使用accountList指称一组帐号 使用读的出来的名称---比如,genymdhms(生成日期,年,月,日,时,分,秒),这个怎么读?? 类名---类名和对象名应该是名词或名词短语,如Customer.WiKIPage.Account,避免使用Manager.Processor.Date这样的类名. 方法名---方法名应当是动词或动词短语. 函数: 短

代码整洁之道札记:格式

前言:东汉大臣陈蕃有一则这样的故事,"一屋不扫何以扫天下",寓意来表明一个大丈夫,如果连自己的居室都不能打扫干净,怎么胸怀天下.<代码整洁之道>就是来劝诫我们程序员写出更优秀的代码,而"格式"一章也恰巧给我们举出了很多原则,以供我们写出更加规整的代码. 格式的目的 好的代码格式,让人赏心悦目,并且随着版本的更迭,让你能够随心所欲的进行变更,而不是每次都痛苦不堪. 垂直格式 类文件的行不应该成千上万行,应尽量保持短小,当然这点很难做到,我们习惯于在一个类中