字段与方法参数


9

我刚开始写一些新的类,然后发现我添加了很多严格不需要的方法参数。这是为了避免在某些方法调用特定的类中具有状态,而不是成为类的常规配置或依赖性,这是一种习惯。

这样做意味着许多没有参数的方法最终只能得到一,二或三。

我想听听您对这个折衷方案的看法,以及如何决定在何种情况下采取哪种方法?

由于在描述代码时,代码通常比英语更容易理解,因此我创建了一个包含两个变体的小知识点:https : //gist.github.com/JeroenDeDauw/6525656


只要有意义,仅用作局部变量(而不是对象生命周期中全局变量)的参数应该在范围内...当开发人员将非实例状态存储为实例状态时,我会感到非常恼火方便...不过我的意见。很难看到执行流程的实际情况。
2013年

使用参数并让类负责执行一个方法时是否必须更改状态,这很好地与“告诉不要问”原理联系在一起。请记住,“不要问”并不意味着您不能查询对象的状态(公然插入
Marjan Venema 2013年

Answers:


2

由于示例中唯一在外部可见的方法是updateTable,所以我认为可以使用字段代替方法参数。

如果这是更通用的类(例如TableTools)的一部分,我会将需要状态的辅助方法移到隐藏的内部类中。

伪代码示例:

class TableTools {
    ...
    public void updateTable(currentTable, newTable) {
        TableUpdater u = new TableUpdater(schemaModifier, currentTable, newTable);
        u.removeRemovedFields();
        u.addAddedFields();
     }

     private class TableUpdater { ... }
}

这样,您可以避免仅使用一种公共方法使用的字段。此外,从每次对updateTable的调用都使用其自己的TableUpdater副本以及TableUpdater实例变量的副本的意义上说,该代码是线程安全的。


7

使用字段可以使使用这些字段的方法具有多线程功能。

从可重用性和可维护性的角度来看,使用这样的字段仅比使用全局变量好一点,这里的重点是复杂的设置需要仔细而最新的文档,以了解哪些方法使用和/或破坏了哪些字段。使用参数时不需要做的事情。


Multhithreading与我的用例无关,就像在PHP中一样。我同意,如果使用字段的方法不是微不足道的,那么这种方法是不好的。在这种情况下,它们只能从唯一的公共方法写入(并始终写入)。我不认为这会引起问题。至于这样的领域只比全局域好一点,我不太确定你的意思。你能详细说明吗?
Jeroen De Dauw 2013年

7

用外行的话来说:

  • 方法应具有尽可能少的参数(Martin的Clean Code)
  • 对象的特征之一就是它们可以(并且应该)具有状态
  • 不对对象状态进行操作(即接收所有内容作为参数)的非静态方法不具有内聚性
  • 非内聚方法也可以设置为静态并分组在实用程序类中

同样,在我的拙见中,非内聚方法属于实用程序类,而不属于具有域名的类。


1

在当前情况下不要使用字段! 同时使用该对象的两个“线程”将严重混淆彼此。它们也不必是真实的,独立的线程(因此使用引号)。如果为一个表设置对象,然后调用将其用于另一张表的方法,然后尝试使用原始设置,则会遇到问题。暂时保留参数。

在此处创建一个仅在一种情况下使用的新更新程序类。原始类可以具有在需要时创建实例的方法。新类将包含字段。你们两全其美。有时,仅坚持使用参数会更简单,但是在您的示例中,您已经到达了一个单独的类更好的地方。


0

我认为,选择应该根据您的实际情况。如果某项属于实例,则应将其视为其字段。如果该项在实例外部,则应将其作为方法参数传递。

在这种情况下,我们不应该以有效性(无论如何是微不足道的)或(上帝保佑!)键入的简便性为指导,而是以代码的易懂性和自然性为指导。


0

在我看来,如果您正在编写对某事做某事的代码,那么它应该使用参数来定义要对某事做的事情,并且其名称应该尽可能地定义对它做什么。

如果您正在编写将要在某物上执行动作打包的代码,则应将应在某物上执行动作包装起来,并将其传递给您执行某事的东西

然后,此操作就成为对第一个方法的调用的一种元描述,您可以稍后在队列中进行排队,甚至出于某种原因决定完全不执行该调用。

所以你的问题转化成是它的一个 动作 或一个 功能?一个动作可以被推迟或取消,因此应该封装它所执行的动作。一个功能,所以没有必要顶部保留其参数立即发生。

您可以撤消操作,但不能撤消功能

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.