最近我的团队中有这样的争论。我们需要创建一个 Powershell 模块，定义几个将在各种脚本中重用的函数。
一些团队成员认为模块中暴露的函数应该将对象作为参数，而不是 2 或 3 个原始类型参数。其他人则认为，如果您查看 Powershell 的基本命令，虽然它们可能返回对象，但它们从不将对象作为参数。
考虑 how tedious与“真正的面向对象”语言相比，它是在 Powershell 中操作对象，您认为值得付出额外的代价吗？是否有任何普遍接受的关于将对象作为输入的最佳实践？
一般来说， Powershell 是否曾经在设计时考虑到了完整的传统面向对象，或者它的命令行特性是否必然会影响我们编写和使用 Powershell 代码的方式？
最佳答案
Others argue that if you look at Powershell's base commands, while they may return objects, they never take objects as parameters.
那是垃圾。
Stop-Process 怎么样，我头顶上的第一个例子？您可以将整数数组(进程 ID)、字符串数组(进程名称)或 Process 数组传递给它。对象:Syntax
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 是最明显的例子)作为对象也很好。
关于oop - Powershell 模块/脚本应该接受对象作为输入吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22711602/