静态方法和实例方法的区别以及如何恰当使用

最近看到同事把一个私有实例方法改成了静态方法,隐约记得有人曾经跟我说过尽量少用静态方法,于是就和同事讨论了下静态方法和实例方法有啥区别,到底怎么用比较合适。

于是在网上搜寻资料,但是很多都是粗略讲了下,或者是复制粘贴的。功夫不负苦心人,终于找到一篇文章说了静态方法和实例方法的文章,并且作者还给出了原文链接:ABAP Static vs Instance method – Which to use when? 

下文直接搬运了 孟雨泊 的知乎文章 静态方法和实例方法的区别以及何时使用

我们都在争论何时使用静态方法或实例方法。 在大多数情况下,我们会采用最简单的方法,但这可能不是正确的方法。 让我们尝试探索并确定在确定“静态”或“实例”时最好的方法是什么。

在跳入差异和应该使用之前,请先检查一下静态方法和实例方法的基础。

静态方法

静态方法是可以与类实例无关地调用的方法。 您只能在Static方法中访问静态属性和静态事件。

实例方法

实例方法是只能使用对象引用调用的方法。 实例方法可以访问实例属性和实例事件。 

为什么不使用静态方法

从示例代码中可以看到,创建静态方法听起来不错,而且很有利可图,因为在调用方法时不涉及冗长的步骤-声明引用变量,实例化对象和调用方法。 无需执行这些步骤即可直接调用静态方法。 但是使用静态的设计不会像听起来那样好。 让我告诉你为什么:

静态方法无法重新定义

面向对象编程的最重要方面之一是多态性–只要需要,就用更具体的实现替换默认实现。在OO ABAP中,多态性将使用方法重新定义来实现。正如我们在前面的文章“覆盖静态方法”中所讨论的,我们无法重新定义静态方法。造成这种情况的主要原因是静态方法可以独立运行。使用静态方法,可以通过显式指定定义它们的类型来调用它们。这意味着,您可以直接调用实现,而该实现不绑定到实例对象的任何特定实现。

让我们通过一个简单的场景来了解这一点–如果您有使用BAPI进行销售订单创建的静态方法。在设计时,此方法仅用于一种业务场景。现在,您想将此用于不同的业务场景。在这种新方案中,您需要在项目上设置一些其他字段,例如“更高级别”项目,确定新项目类别等。您认为简单的解决方案是在方法中添加一个代码块来执行此逻辑XYZ销售区域,ZABC订单类型。您在这里所做的事情是打开一个框,您将在其中继续添加越来越多的条件。因此违反了单一责任原则。

如果您具有Instance方法,则可以轻松继承另一个类,重新定义该方法并替换现有的实现。在这个新的实现中,您将设置其他字段并调用Super Method来完成其余的工作。

单元测试

测试夹具

在ABAP单位中,可以使用称为测试夹具的特殊方法设置测试数据。使用此方法后,将在您有权访问测试数据的地方调用您的测试方法。由于每个ABAP单元测试都应该可以单独进行操作和测试,因此静态方法很难进行测试。静态方法将使用静态属性,并且由于它们正在使用静态属性,因此您必须在测试夹具方法中始终具有其他逻辑来摆脱它们。

如果您正在使用实例的对象,则可以轻松清除它。当实例化一个新对象时,旧对象将被取消引用而无需任何其他逻辑

构造函数

与实例方法的CONSTRUCTOR方法相反,使用静态方法的设计最终将使用CLASS_CONSTRUCTOR。 如前所述,CLASS_CONSTRUCTOR and CONSTRUCTOR: Who comes before whom?,很难预测何时调用CLASS_CONSTRUCTOR。 首次访问该类时可以调用CLASS_CONSTRUCTOR,即使已访问该类以获得常量值也是如此。 这使其无法操作且无法测试。

在同一会话中重用该实用程序

静态属性将绑定到内存,直到会话结束。这意味着,如果仅设置一次值,则在会话结束之前不会清除它们。如果是静态属性,则不可能在同一会话中利用相同的逻辑。例如。一个简单的实用程序类,用于生成应用程序日志。

举个例子:

  • 在静态类的属性中收集日志
  • 收集后调用静态方法以生成应用程序日志。

该设计似乎完全适合应为静态的实用程序类。但这是一个问题,它限制了您在同一会话中再次使用相同的逻辑而不会丢失现有信息。可以说,您正在使用此应用程序日志收集错误。现在,在同一程序中,您将不会生成另一个应用程序日志来跟踪执行的活动。由于您已收集了静态属性中的所有错误,因此除非将其复制到另一个占位符并调用Utility类以生成跟踪日志,否则当您尝试使用同一Utility类时,您将丢失错误日志数据。

另一方面,您使用实例方法和属性进行了设计,则可以简单地创建另一个实例并开始使用它来跟踪日志。

总结

因此,基于所有这些事实,我们可以得出以下经验法则:

  • 如果打算创建静态方法将使用的任何静态属性,请考虑创建实例方法。它将允许您使用多个实例。它还允许您控制何时可以释放绑定的内存。

  • 如果您认为将来有机会添加条件逻辑,请使用实例方法。通过利用Redefinition,利用多态来使设计更加灵活

  • 静态仅应用于对象创建的设计模式,例如Singleton,Factory Method,Abstract Factory,Singleton Factory,以方便对象创建。

  • 静态应该用于纯实用程序类,而不用于助手类。

 

文章看完后,我简单说下我的理解:

  • 静态方法之所以不推荐使用是因为其缺乏扩展性,一旦使用静态方法,面向对象的继承多态特性也就不再适用。后续在往静态方法中添加逻辑就会出现很多 if else,因为你无法保证不同业务方的要求是一样的。比较好的做法是创建一个接口或者抽象类,让不同业务场景自己去实现,这样即使变化也不会相互影响。

  • 如果一定要使用静态方法,一定要确保该方法以后不会再出现修改和迭代。静态方法适用场景:工具方法比如 Math.max(),文件读写,单例,工厂模式等;

  • 如果是并发场景,也不推荐使用静态方法,你无法保证线程安全,有可能存在多个线程同时调用,此时你无法确定得到的结果是否是对的。如果给静态方法添加锁就得不偿失了,此时,实例方法是一个好的选择。

posted @ 2021-10-20 00:09  huansky  阅读(1388)  评论(0编辑  收藏  举报