javascript类方法应该决定是否执行它们，还是应该由被调用者决定是否调用？ - 腾讯云开发者社区

当调用使用值接收者声明的方法时，会使用这个值的一个副本来执行，即用于消费这个接收者,不会对原有接收有影响。...需要说明的是GOlang对方法的调用者很宽松，既允许使用值，也允许使用指针来调用方法，不必严格符合接收者的类型。...这个函数传入了一个 int8类型的值，并返回一个bool 类型的值，这里的参数没有使用指针来共享参数的值，调用者传入了一个uint8值的副本，接受一个返回值 true 或者 false。...至于是使用返回的值替换原来的 Time 值，还是创建一个新的 Time 变量来保存结果，是由调用者决定的事情。非原始的情况大多数情况下,结构类型的本质并不是原始的,而是非原始的。...因为 File 类型的值具备非原始的本质，所以总是应该被共享，而不是被复制。「是使用值接收者还是指针接收者,不应该由该方法是否修改了接收到的值来决定。这个决策应该基于该类型的本质。」

3633 0

答应我，别再写上千行的类了好吗

），如果一个类的职责很多，那它的扇入（调用者）一定很多，每个调用者的修改都有可能让你这个类不得不随之修改，也就是发散式变化就是说不管哪儿出了问题，你这个类都得遭殃发散式修改（指此类修改引发修改的地方很多...），相同的，如果一个类职责很多，那支撑它实现的下级，即扇出（被调用方）一定很多，如果此类逻辑发生变动，所有下级被调用者可能都得随之修改，也就是发散式修改就是说你这个类出了问题，不管哪儿都会遭殃难以扩展...图中成员【偏A】被类【A】调用两次，而只被它所在的类【过长类】调用1次，因而应该转移给【A】去管理由于函数【偏A】与成员【偏A】的亲密度较高（只调用了【偏A】），因而应与【偏A】共进退，同去留，转移给...【A】成员【偏B】和函数【偏B】也是相同道理职责1（函数【1】和成员【偏职责1】）和职责2（函数【2】和成员【偏职责2】）由于找不到可转移的合适的类，所以应抽取出一个新的类注意，先决定移动哪个成员变量...注意，抽取的函数和成员一定要符合一个原则，那就是被抽取函数使用被抽取成员的次数一定高于剩余函数的次数，不然违反亲密性原则（成员应归于调用它最多的类，没有理由你用的比我多还让我来管理）一些小问题由于抽取的函数直接使用了未抽取的对象而导致重构失败

4393 0

您找到你想要的搜索结果了吗？

是的

没有找到

900行又臭又长的类重构，几分钟搞定

，还会让你的类难以扩展，甚至会让其他程序猿认为你不专业发散式变化（指引发此类修改的地方很多），如果一个类的职责很多，那它的扇入（调用者）一定很多，每个调用者的修改都有可能让你这个类不得不随之修改，也就是发散式变化...就是说不管哪儿出了问题，你这个类都得遭殃发散式修改（指此类修改引发修改的地方很多），相同的，如果一个类职责很多，那支撑它实现的下级，即扇出（被调用方）一定很多，如果此类逻辑发生变动，所有下级被调用者可能都得随之修改...扫把() × Tom.用扫把扫地() × 重构——转移成员变量+函数（转移职责）将不应该由自己管理的成员变量和函数转移出去那就要考虑两个问题：该转移谁？...来看一个图图中成员【偏A】被类【A】调用两次，而只被它所在的类【过长类】调用1次，因而应该转移给【A】去管理由于函数【偏A】与成员【偏A】的亲密度较高（只调用了【偏A】），因而应与【偏A】共进退，...，那就是无用对象了，不如直接把他们删除掉 2.为新类起个名，选个包吧 3.注意，抽取的函数和成员一定要符合一个原则，那就是被抽取函数使用被抽取成员的次数一定高于剩余函数的次数，不然违反亲密性原则（成员应归于调用它最多的类

1973 0

一个类写几千行？该改改啦！

，还会让你的类难以扩展，甚至会让其他程序猿认为你不专业发散式变化（指引发此类修改的地方很多），如果一个类的职责很多，那它的扇入（调用者）一定很多，每个调用者的修改都有可能让你这个类不得不随之修改，也就是发散式变化...就是说不管哪儿出了问题，你这个类都得遭殃发散式修改（指此类修改引发修改的地方很多），相同的，如果一个类职责很多，那支撑它实现的下级，即扇出（被调用方）一定很多，如果此类逻辑发生变动，所有下级被调用者可能都得随之修改...扫把() × Tom.用扫把扫地() × 重构——转移成员变量+函数（转移职责）将不应该由自己管理的成员变量和函数转移出去那就要考虑两个问题：该转移谁？...来看一个图图中成员【偏A】被类【A】调用两次，而只被它所在的类【过长类】调用1次，因而应该转移给【A】去管理由于函数【偏A】与成员【偏A】的亲密度较高（只调用了【偏A】），因而应与【偏A】共进退，...，不如直接把他们删除掉为新类起个名，选个包吧注意，抽取的函数和成员一定要符合一个原则，那就是被抽取函数使用被抽取成员的次数一定高于剩余函数的次数，不然违反亲密性原则（成员应归于调用它最多的类，没有理由你用的比我多还让我来管理

3924 0

求求你别再写上千行的类了，试试 IDEA 这些牛逼的重构技巧吧

、类过长等代码问题，还会让你的类难以扩展，甚至会让其他程序猿认为你不专业 2、发散式变化（指引发此类修改的地方很多），如果一个类的职责很多，那它的扇入（调用者）一定很多，每个调用者的修改都有可能让你这个类不得不随之修改...，所有下级被调用者可能都得随之修改，也就是发散式修改就是说你这个类出了问题，不管哪儿都会遭殃 4、难以扩展，如果你的一个类接口非常多，那它的子类怎么办？...比如： Tom.扫地() √ Tom.扫地With扫把() × Tom.用扫把扫地() × 重构——转移成员变量+函数（转移职责）将不应该由自己管理的成员变量和函数转移出去那就要考虑两个问题：该转移谁...来看一个图图片图中成员【偏A】被类【A】调用两次，而只被它所在的类【过长类】调用1次，因而应该转移给【A】去管理由于函数【偏A】与成员【偏A】的亲密度较高（只调用了【偏A】），因而应与【偏A】共进退...，同去留，转移给【A】成员【偏B】和函数【偏B】也是相同道理职责1（函数【1】和成员【偏职责1】）和职责2（函数【2】和成员【偏职责2】）由于找不到可转移的合适的类，所以应抽取出一个新的类注意，先决定移动哪个成员变量

6491 0

「设计模式 JavaScript 描述」模板方法模式

既然父类规定了子类的方法和执行这些方法的顺序，子类就应该拥有这些方法，并且提供正确的实现。 3.2 抽象方法和具体方法抽象方法被声明在抽象类中，抽象方法并没有具体的实现过程，是一些“哑”方法。...钩子方法的返回结果决定了模板方法后面部分的执行步骤，也就是程序接下来的走向，这样一来，程序就拥有了变化的可能。...在这一原则的指导下，我们允许底层组件将自己挂钩到高层组件中，而高层组件会决定什么时候、以何种方式去使用这些底层组件，高层组件对待底层组件的方式，跟演艺公司对待新人演员一样，都是“别调用我们，我们会调用你...模板方法模式是好莱坞原则的一个典型使用场景，它与好莱坞原则的联系非常明显，当我们用模板方法模式编写一个程序时，就意味着子类放弃了对自己的控制权，而是改为父类通知子类，哪些方法应该在什么时候被调用。...这也相当于好莱坞原则中提到的“别调用我们，我们会调用你”。回调函数在 ajax 异步请求中，由于不知道请求返回的具体时间，而通过轮询去判断是否返回数据，这显然是不理智的行为。

2451 0

线程池的使用

■ **CallerRunsPolicy：**只要线程池未关闭，该策略直接在调用者线程中运行当前被丢弃的任务。显然这样不会真的丢弃任务，但是，调用者线程性能可能急剧下降。...■ execute() 方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功。通过代码可知 execute() 方法输入的任务是一个 Runnable 类的实例。...它们的原理是遍历线程池中的工作线程，然后逐个调用线程的 interrupt 方法来中断线程，所以无法响应中断的任务可能永远无法终止。...至于应该调用哪一种方法来关闭线程池，应该由提交到线程池的任务来决定，通常调用shutdown 方法来关闭线程池，如果任务不一定要执行完，就可以调用 shutdownNow 方法。...至于应该调用哪一种方法来关闭线程池，应该由提交到线程池的任务来决定，通常调用shutdown 方法来关闭线程池，如果任务不一定要执行完，就可以调用 shutdownNow 方法。

5473 0

求你们了，别再写上千行代码的类好吗？

，还会让你的类难以扩展，甚至会让其他程序猿认为你不专业 2、发散式变化（指引发此类修改的地方很多），如果一个类的职责很多，那它的扇入（调用者）一定很多，每个调用者的修改都有可能让你这个类不得不随之修改，...，所有下级被调用者可能都得随之修改，也就是发散式修改，就是说你这个类出了问题，不管哪儿都会遭殃 4、难以扩展：如果你的一个类接口非常多，那它的子类怎么办？...）将不应该由自己管理的成员变量和函数转移出去那就要考虑两个问题：该转移谁？...来看一个图 1、图中成员【偏A】被类【A】调用两次，而只被它所在的类【过长类】调用1次，因而应该转移给【A】去管理 2、由于函数【偏A】与成员【偏A】的亲密度较高（只调用了【偏A】），因而应与【偏A...，那就是无用对象了，不如直接把他们删除掉 2）为新类起个名，选个包吧 3）注意，抽取的函数和成员一定要符合一个原则，那就是被抽取函数使用被抽取成员的次数一定高于剩余函数的次数，不然违反亲密性原则（成员应归于调用它最多的类

1.1K3 0

Java 异常处理的 9 个最佳实践

2、优先明确异常你抛出的异常越明确越好，永远记住，你的同事或者几个月之后的你，将会调用你的方法并且处理异常。因此需要保证提供给他们尽可能多的信息。这样你的 API 更容易被理解。...你的方法的调用者能够更好的处理异常并且避免额外的检查。...3、记录指定的异常每当你在方法签名中指定异常，你也应该在 Javadoc 中记录它。这与上一个最佳实践具有相同的目标：尽可能多地向调用者提供信息，以便避免或处理异常。...但这一次，你不会将信息提供给方法的调用者。每个必须了解在日志文件或监视工具中报告异常情况时发生了什么情况的人都可以读取异常消息。因此，应该尽可能精确地描述问题，并提供最相关的信息来了解异常事件。...或者是抛出异常的代码被改变，现在抛出同一个类的多个异常，而调用的代码并不能阻止所有异常。你至少应该写一条日志信息，告诉大家这个不可思议的事发生了，而且有人需要检查它。 ?

7689 0

《Head First 设计模式》学习心得笔记

工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个（决定的意思是指：在编写创造者类时，不需要知道实际创建的产品是哪一个）。...），应该派生自一个抽象（接口或者抽象类）；不要覆盖基类中已经实现的方法（基类中已经实现的方法，应该由所有子类共享）；抽象工厂模式：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。...调用者 (Invoker)只要调用 execute() 方法就可以发出请求，然后由具体命令对象 (ConcreteCommand) 调用接收者 (Receiver) 的一个或多个动作；接收者 (Receiver...对于最少知识原则，对任何对象而言，在该对象的方法内，我们应该调用属于以下范围内的方法：该对象本身；被当作输入参数而传递进来的对象；该方法所创建或实例化的任何对象（即局部变量）；该对象的任何组件...当子类必须提供算法中的某个方法或步骤的实现时，使用抽象方法；如果算法的这个部分是可选的，就用钩子（钩子即为在抽象类中，什么事情都不做的一个具体方法，可以让子类有能力对算法的不同点进行挂钩，且由子类自行决定是否需要挂钩

4803 0

关于如何实现一个TCC分布式事务框架的一点思考

重试时会再次调用各TCC服务的Confirm/Cancel业务方法。如果某个服务的Confirm/Cancel业务之前已经生效（其参与的RM本地事务已经提交），重试时就不应该再次被调用。...否则，其Confirm/Cancel业务方法被多次调用，就会有“服务幂等性”的问题。 2.2....因此，这类业务方法上的异常情况并不能反映他们是否生效。不接管Spring的TransactionManager，就无法了解事务于何时被创建，也无法了解它于何时被提交/回滚。...而一个事务应该被commit还是被rollback，则应该是由Spring容器来决定的：Spring决定提交事务时，会调用TransactionManager来完成commit操作；Spring决定回滚事务时...既然Confirm/Cancel业务可能会被多次调用，就需要保障其幂等性。那么，应该由TCC事务框架来提供幂等性保障？还是应该由业务系统自行来保障幂等性呢？

1K1 0

Effective Java要点笔记

equels方法诀窍： == 判断是否是同一个对象的引用 instanceof 进行类型检查把参数转换为正确的类型检查参数的每个域是否一一对应的equals 覆盖equals必须覆盖hashCode...当非静态成员类的实例被创建的是时候，它和外围实例之间的关联关系也随之建立起来&不能被修改每当编写方法和构造器的时候，应该考虑他它的参数有哪些限制，应该把限制写到文档中，并在方法的开头处加上限制逻辑，私有方法...要注意是否允许调用者修改其内部的组件，关于方法签名的设计：方法名称尽量要风格一致，并选择大众认可的名称类的方法设计太多，会使类难以学习，使用，文档化，测试以及维护避免过长的参数列表，目标参数个数...（Throwable.getCause）来获取底层的异常不过我们应该在底层方法调用的时候尽量确保它们会执行成功，从而避免它们抛出异常，比如通过严格的检查高层传递到底层的参数。...次选方案是，让高层悄悄的绕开异常，将高层方法的调用者与底层问题隔离起来。（底层catch异常打错误日志）一般而言，失败的方法调用应该使对象保持在被调用之前的状态异常要打印关键信息，禁止忽略异常

4091 0

如何实现一个TCC分布式事务框架的一点思考

掌握每个RM本地事务的状态以及它们与Try/Confirm/Cancel业务方法之间的对应关系，以此为基础，TCC事务框架才能有效的构建TCC全局事务。...比如，被传播事务上下文的业务方法，在它开始执行时，容器并不会为其创建新的事务，而是它的调用方参与的事务，使得二者操作在同一个事务中；同样，在它执行完毕时，容器也不会提交/回滚它参与的事务的。...因此，这类业务方法上的异常情况并不能反映他们是否生效。不接管Spring的TransactionManager，就无法了解事务于何时被创建，也无法了解它于何时被提交/回滚。...而一个事务应该commit、还是rollback，则应该是由Spring容器来决定的：Spring决定提交事务时，会调用TransactionManager来完成commit操作；Spring决定回滚事务时...既然Confirm/Cancel业务可能会被多次调用，就需要保障其幂等性。那么，应该由TCC事务框架来提供幂等性保障？还是应该由业务系统自行来保障幂等性呢？

1K2 0

Effective-java-读书笔记之异常

exception).运行时异常(run-time exception).错误(error).决定使用受检异常或是非受检异常时, 主要的原则: 如果期望调用者能够适当地恢复, 对于这种情况就应该使用受检的异常...大多数运行时异常都表示前提违例, 例如数组越界访问.如果无法决定到底应该用受检(checked exception)还是非受检异常(runtime exception), (无法确定是否可能恢复), 就用...(有时候可以通过检查高层传入底层的参数实现.)如果底层异常的确不可避免, 让高层默默解决这些异常, 从而使高级别方法的调用者与低层问题隔离...., 然后只要把它们放到消息描述中, 就可以自动产生细节信息.第76条努力使失败保持原子性失败原子性(failure atomic): 失败的方法调用应该使对象保持在被调用之前的状态.实现这种效果的途径...:设计一个不可变的对象.在执行操作之前检查参数的有效性, 在对象的状态被修改之前抛出适当的异常. -> 让可能会失败的计算部分都在对象状态被修改之前发生.在对象的一份临时拷贝上执行操作, 当操作完成后再用临时拷贝中的结果代替对象的内容

4896 1

避免Java应用程序中NullPointerException的技巧和最佳实践

如果调用者为空，则此调用的一个副作用就是可能导致NullPointerException。...集合类提供方便的空的List, Set 和Map方法：Collections.EMPTY_LIST ，Collections.EMPTY_SET 和Collections.EMPTY_MAP ，可以相应地使用它们...通过查看 @NotNull 和@Nullable ，程序员自己可以决定是否检查null。顺便说一句，对于Java程序员来说，这是相对较新的最佳实践，要花些时间才能被利用起来。...一个相同的注释，通过定义什么可以为空和什么不能为空，调用者可以做出明智的决定。选择fast-fail还是接受null也是您需要采取并坚持一致的重要设计方法。...如果某个方法返回一个对象，该对象将在调用方上执行，例如Collection.iterator()方法返回Iterator，则调用方将在该迭代器上执行遍历。

1K5 0

java异常处理(学习笔记)

使用throws声明抛出异常使用throws抛出异常的思路是：当前方法不知道如何处理这种类型的异常，该异常应该由上一级调用者处理，如果main方法也不知道如何处理这种类型的异常，也可以使用throws...如果某段代码中调用了一个带throws声明的方法，该方法抛出了Checked异常，则表明该方法希望它的调用者来处理该异常。...也就是说，在异常出现的当前方法中，程序只对异常进行部分处理，还有些处理需要在该方法的调用者中才能完成，所以应该再次抛出异常，让该方法的调用者也能捕获到异常。...，首先传给该方法的调用者，该方法调用者再次传给其调用者,直至最后传到main方法，如果main方法依然没有处理该异常，JVM会中止该程序，并打印异常的跟踪栈信息。...第一行的信息详细显示了异常的类型和异常的详细信息，接下来跟踪栈记录程序中所有的异常发生点，各行显示被调用方法中执行的停止位置，并标明类、类中的方法名、与故障点对应的文件的行。

6001 1

进阶 | 全方位解读this

在一个函数上下文中，this由调用者提供，由调用函数的方式来决定。如果调用者函数，被某一个对象所拥有，那么该函数在调用时，内部的this指向该对象。...从结论中我们可以看出，想要准确确定this指向，找到函数的调用者以及区分他是否是独立调用就变得十分关键。...再来看一些容易理解错误的例子，加深一下对调用者与是否独立运行的理解。 foo.getA()中，getA是调用者，他不是独立调用，被对象foo所拥有，因此它的this指向了foo。...三、使用call，apply显示指定this JavaScript内部提供了一种机制，让我们可以自行手动设置this的指向。它们就是call与apply。所有的函数都具有着两个方法。...我们常常会用到这方法，但是我们也要借助上面讲到过的知识，来判断this是否在传递中被修改了，如果没有被修改，就没有必要这样使用了。另外就是借助闭包与apply方法，封装一个bind方法。

2941 0

蓝桥ROS机器人之C++基础2总结和测评

函数调用是告诉 CPU 执行函数的表达式。发起函数调用的函数是调用者，被调用的函数是被调用者或被调用函数。进行函数调用时不要忘记包含括号。函数定义中的花括号和语句称为函数体。...return 语句确定返回给调用者的具体返回值。这个过程称为按值返回。如果函数不向调用者返回值，则它们的返回类型可以是void 。未能从非 void 函数返回值将导致未定义的行为。...函数main的返回值称为状态码，它告诉操作系统（以及任何其他调用程序）程序是否成功执行。按照共识，返回值 0 表示成功，正返回值表示失败。函数参数是函数中使用的变量，其值由函数的调用者提供。...变量的作用域决定了它可以在哪里被访问。当一个变量可以被访问时，我们说它在范围内。当它无法访问时，我们说它超出了范围。Scope 是一个编译时属性，这意味着它在编译时强制执行。...该程序应使用三个功能：应该使用名为“readNumber”的函数从用户那里获取（并返回）一个整数。应该使用名为“writeAnswer”的函数来输出答案。这个函数应该接受一个参数并且没有返回值。

7194 0

NodeJS错误处理最佳实践

我应该检查更加具体的约束么？例如参数是否非空，是否大于零，是不是看起来像个IP地址，等等等。我该如何处理那些不符合预期的参数？我是应该抛出一个异常，还是把错误传递给一个callback。...我怎么才能提供足够的信息让调用者知晓错误细节。我该怎么处理未预料的出错？我是应该用 try/catch ，domains 还是其它什么方式呢？...通常，只有顶层的调用者知道正确的应对是什么，是重试操作，报告给用户还是其它。但是那并不意味着，你应该把所有的错误全都丢给顶层的回调函数。...此外，你还要记录： 调用者可能会遇到的操作失败（以及它们的name）怎么处理操作失败（例如是抛出，传给回调函数，还是被 EventEmitter 发出）返回值使用 Error 对象或它的子类，并且实现...在写新函数的时候，用文档清楚地记录函数预期的参数，包括它们的类型、是否有其它约束（例如必须是有效的IP地址），可能会发生的合理的操作失败（例如无法解析主机名，连接服务器失败，所有的服务器端错误），错误是怎么传递给调用者的

1.5K4 1

重构-改善既有代码的设计：简化函数调用（八）

不过你应该先检查调用者任何使用这个函数，以决定是否值得这么做。...如果调用者不需要了解函数所属的类，你也可以继续保持调用者无知而幸福的状态。...如果某个参数有多种可能的值，而函数内又以条件表达式检查这些参数值，并根据不同参数值做出不同的行为，那么就应该使用本项重构。调用者原本必须赋予参数适当的值，以决定该函数做出何种响应。...这样你的意图会更加清晰，并且可以排除其值被修改的可能性。如果你保留了间接访问变量的方法，就可能经常有程序员盲目使用它们。这些人甚至会在构造函数中使用设值函数。...随着越来越多行为被放入这个类，你会发现许多设值/取值函数不再需要被公开，因此可以将它们隐藏起来。

4491 0

点击加载更多

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云

GO语言实战之类型的本质

答应我，别再写上千行的类了好吗

900行又臭又长的类重构，几分钟搞定

一个类写几千行？该改改啦！

求求你别再写上千行的类了，试试 IDEA 这些牛逼的重构技巧吧

「设计模式 JavaScript 描述」模板方法模式

线程池的使用

求你们了，别再写上千行代码的类好吗？

Java 异常处理的 9 个最佳实践

《Head First 设计模式》学习心得笔记

关于如何实现一个TCC分布式事务框架的一点思考

Effective Java要点笔记

如何实现一个TCC分布式事务框架的一点思考

Effective-java-读书笔记之异常

避免Java应用程序中NullPointerException的技巧和最佳实践

java异常处理(学习笔记)

进阶 | 全方位解读this

蓝桥ROS机器人之C++基础2总结和测评

NodeJS错误处理最佳实践

重构-改善既有代码的设计：简化函数调用（八）

扫码

相关资讯

热门标签

活动推荐

运营活动

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐