Product and service reviews are conducted independently by our editorial team, but we sometimes make money when you click on links. Learn more.

Object-Oriented PowerShell Module Design

Object-Oriented PowerShell Module Design

As your PowerShell modules get more complex, planning and design start to become necessary. Using an object-oriented approach can help you create more manageable, scalable PowerShell modules.

If you're just starting out creating PowerShell modules, design probably isn't the first idea to come to your head. You're more likely to think about simply placing similar functions in a module and running Import-Module to bring them into your console session for use. That's the typical way we all learn about modules. This method is perfectly fine until you begin to build larger and larger modules.

Eventually, you may even end up breaking apart that one large module into multiple modules so you can manage them easier. At this point, you'll find that nonchalantly putting functions inside of these modules isn't scalable. Before you know it, you'll have functions in one module using functions in the other, and those functions will have dependencies on something else that also calls something else and so on. Soon, you'll see just how important a good initial planning session can be in creating manageable, scalable PowerShell modules. 

One way to design PowerShell modules is to use an object-oriented approach. The phrase "object oriented" comes from object oriented programming (OOP). OOP is a style of programming that insists you create objects, properties and methods to represent real business cases rather than expressing code simply with functions. There are reams of books on the topic of OOP, but without going into a lot of detail, the basic premise for our purposes is defining all the objects and properties, and figuring out what, if any, parent/child object relationships exist.

NOTE: We will be using loose OOP terminology in an attempt to relate OOP to PowerShell modules and functions. The terms we will be using are not official terms by any means, thus they will be enclosed in quotes to reflect this.

MORE: PowerShell Tutorials

Defining The "Parent Object"

The first step is figuring out what your "parent object" is. This is typically a shared concept across all of your functions. If you're designing a PowerShell module to manage local accounts on a Windows system, for example, your "parent object" would be LocalAccount. You'll want to include users and groups in this, but notice that we didn't call it LocalUser or LocalGroup -- that's too specific. It's a term that will describe all of your "child objects" within the module. The "parent object" will be the name of your module.

Defining The "Child Objects"

Once you've figured out the "parent object"/module name you should think about any "child objects" that you may need to manage. In our case, we probably want to manage groups as well as users in our module. This would mean we would have a group "child object" and a user "child object." Can you think of anything else that might be considered a local account? If not, it's now time to define your "methods."

Defining The Object "Methods"

By now, we've got a module called LocalAccount and two "child objects" (User and Group). Next, we need to do "stuff" to those users and groups, right? What actions are typically taken on these accounts? By default, you should always include the four common "methods:" Add, Remove, Set and Get. These "methods" follow the standard Verb-Noun PowerShell naming convention. By following this method this would give us Add/Remove/Set/Get-LocalUser and Add/Remove/Set/Get-LocalGroup. These would be our "core" functions. You may have other helper functions to assist in running these "core" functions but these would be what the user typically interacts with.

What do think of this approach to module design? Can you see the benefit of thinking ahead and designing your modules like objects would make things much easier to manage?

This is just a quick and dirty primer to the concept of object oriented PowerShell module design. Read up on OOP and try out other ways to mimic OOP behavior in PowerShell!