混合的类/对象和函数:有代码气味吗?

时间:2019-09-02 18:47:20

标签: function powershell class

我正在考虑将其迁移到OOP,因为我已为所有用户强制使用PS5,并且代码中的某些内容确实可以从继承中受益。我的脚本具有许多在各个地方使用的实用程序功能。其中有些在我的类中创建辅助方法很有意义,但有些将仅在一个类中使用。那么,将它们保留为Function是合适的吗,或者只是代码太小而应将所有内容都转换为Classes和Objects?如果将实用程序功能转换为OOP,则在其他类之间共享该功能的机制是什么?您是否使用全局变量,是否创建了局部变量并向需要它的对象传递了一些内容?

1 个答案:

答案 0 :(得分:1)

我花费了大量时间来编写PowerShell类,只是为了探索日常工作中的方式/方式/原因,并且在这样做的过程中,我开始问自己以下问题:

  1. 我要创建这个东西的多个实例吗?
  2. 我是否需要它始终具有这些特定的属性和方法?
  3. 这会使我的脚本以后很难理解吗?

对于问题一,当它可能很容易成为自己的.ps1脚本中包含的一系列函数和变量时,它将帮助防止在仅要创建一个实例的类上创建额外的复杂性

对于第二个问题,您可以通过消除根本不需要严格定义的类来进一步过滤掉不必要的复杂性。如果您对包含内部结构化数据的单个字符串数组有两个函数,则最好将时间花费在确保函数本身简洁明了和文档化上,而不是尝试将其转换为类定义。

最后一个问题三,如果您正在处理当前或将来可能传递给另一个人的脚本,则需要询问这种生活质量调整是否会使脚本的意图更难了解。通常这不是问题,但是如果您要解决OOP概念的内在程序/功能问题,那么您只会混淆实际的解决方案。

最后,要解决您对类之间共享信息的担忧,只需在需要在实例或函数之间共享它们的类属性,并在创建实例的范围内引用这些值,就可以公开类属性。

例如,假设我有一个带有属性Bar的Class Foo,我想从脚本函数访问它:

Class Foo {
    [Int] $Bar = 0
    Foo () { $Bar = 5 }
}

$MyVar = [Foo]::New()

Function GetBar() {
    return $Script:MyVar.Bar
}

Write-Host GetBar