我的团队最近一直在争论。我们需要创建一个 Powershell 模块，定义几个将在各种脚本中重用的函数。
一些团队成员认为模块中公开的函数应该将对象作为参数，而不是 2 或 3 个原始类型参数。其他人则认为，如果您查看 Powershell 的基本命令，虽然它们可能返回对象，但它们从不将对象作为参数。
考虑到how tedious 与“真正的面向对象”语言相比，它是在 Powershell 中操作对象，您认为值得付出额外的代价吗？是否有任何普遍接受的关于将对象作为输入的最佳实践？
一般来说，Powershell 的设计是否考虑到了完整的传统面向对象，或者它的命令行特性必然会影响我们编写和使用 Powershell 代码的方式？
【问题讨论】：
标签： oop powershell
其他人认为，如果您查看 Powershell 的基本命令，虽然它们可能返回对象，但它们从不将对象作为参数。
那是垃圾。 Stop-Process 怎么样，我想到的第一个例子？您可以将整数数组（进程 ID）、字符串数组（进程名称）或 Process 对象数组传递给它：
语法
Stop-Process [-Id] <int[]> [-PassThru ] [-Force ] [-WhatIf ] [-Confirm ] [<CommonParameters>] Stop-Process -Name <string[]> [-PassThru ] [-Force ] [-WhatIf ] [-Confirm ] [<CommonParameters>] Stop-Process [-InputObject] <Process[]> [-PassThru ] [-Force ] [-WhatIf ] [-Confirm ] [<CommonParameters>]
或者可能是Remove-Item，它接受-Path 或-LiteralPath 参数，但同样接受具有Path 或LiteralPath 属性的任何对象。此外，与许多其他 cmdlet 一样，它有一个 -Credential 参数，它是一个 pscredential 对象，可以在命令行中指定，也可以作为管道对象的属性。
将这些标准 cmdlet 中的一些作为您的模型：cmdlet 的主要参数通常是一些原语的数组，但也可以是管道中适当对象的属性或对象数组。如果有适当的对象，则接受它作为参数集之一，但尝试使用其他参数集以允许命令自行运行。
其他参数（-Credential 是最明显的例子）作为对象也可以。
【讨论】：
我会使用原始类型作为参数 (KISS)。无论如何，Powershell 在内部都会将所有东西都变成 PSObjects。不管你给它苹果还是橙子，它都会是水果沙拉。
除此之外，随着云计算变得越来越普遍并且远程管理成为常态，您使用的任何东西都更有可能最终被序列化并通过网络发送。原始类型通常更高效且可预测地进行序列化，并且产生的有效负载比 dotnet 对象小得多。
恕我直言
【讨论】：