{"id":11594,"date":"2016-03-16T06:00:00","date_gmt":"2016-03-16T13:00:00","guid":{"rendered":"https:\/\/www.sapien.com\/blog\/?p=11594"},"modified":"2016-03-16T11:45:31","modified_gmt":"2016-03-16T18:45:31","slug":"inheritance-in-powershell-classes","status":"publish","type":"post","link":"https:\/\/dev.sapien.com\/blog\/2016\/03\/16\/inheritance-in-powershell-classes\/","title":{"rendered":"Inheritance in PowerShell Classes"},"content":{"rendered":"

If you’re learning about classes in Windows PowerShell 5.0, one of the first new concepts that you’ll encounter is inheritance<\/i>. When you create a class that is based on another class, your new subclass<\/i> or child class <\/i>automatically gets the inheritable<\/a> members (e.g. properties and methods) of the parent class or base class<\/i>.<\/p>\n

Inheritance is a really powerful and useful concept, so it’s important that you understand it. Fortunately, it’s pretty easy. Also, the inheritance principles that you learn in PowerShell are also used in other programming languages, so learning them in PowerShell gives you a head start on new languages.<\/p>\n

Subclasses of System.Object<\/h1>\n

All PowerShell classes are subclasses of the System.Object class. So, they inherit the inheritable methods of the System.Object class.<\/p>\n

Create an empty class.<\/p>\n

PS C:\\> class AnyClass {}<\/pre>\n
Look at its type. The BaseType property shows the immediate parent class.<\/p>\n
PS C:\\ > [AnyClass]\r\n\r\nIsPublic IsSerial Name     BaseType\r\n-------- -------- ----     --------\r\nTrue     False    AnyClass System.Object<\/pre>\n
And, when you create an instance of the AnyClass class and pass it to Get-Member, you can see that there are four methods of the AnyClass class that you didn’t define. These methods are inherited<\/i> from the System.Object base class.<\/p>\n
PS C:\\> $anything = New-Object -TypeName AnyClass\r\n\r\nPS C:\\> $anything | Get-Member\r\n\r\nTypeName: AnyClass\r\n\r\nName        MemberType    Definition\r\n----        ----------    ----------\r\nEquals      Method        bool Equals(System.Object obj)\r\nGetHashCode Method        int GetHashCode()\r\nGetType     Method        type GetType()\r\nToString    Method        string ToString()<\/pre>\n
You can call these methods on the instance of the AnyClass class. They work as though you wrote them in the AnyClass class.<\/p>\n
PS C:\\> $anything.GetType()\r\n\r\nIsPublic IsSerial Name     BaseType\r\n-------- -------- ----     --------\r\nTrue     False    Anyclass System.Object\r\n\r\nPS C:\\> $anything.ToString()\r\nAnyclass<\/pre>\n
NOTE: All PowerShell classes are automatically subclasses of System.Object. You do not need to specify System.Object as the base class.<\/p>\n
Create a subclass<\/h1>\n
Creating a subclass is easy.<\/p>\n
Let’s create a base class and a subclass. Here’s the Glass class. The full code is in Glass.ps1<\/a> on GitHub. If you’re testing this code, be sure to dot-source the file so that the class is added to the session.<\/p>\n
class Glass\r\n{\r\n    # Properties\r\n    [int]$Size\r\n    [int]$CurrentAmount\r\n\r\n    # Constructors\r\n    Glass ([int]$Size, [int]$Amount)\r\n    {\r\n        $this.Size = $Size\r\n        $this.CurrentAmount = $Amount\r\n    }\r\n\r\n    # Methods\r\n  + [Boolean] Fill ([int]$volume)\r\n    {}\r\n\r\n  + [Boolean] Drink ([int]$amount)\r\n    {}\r\n}<\/pre>\n
The syntax for a subclass is:<\/p>\n
class subclass : base class { ... }<\/pre>\n
PowerShell classes can inherit from only one base class, so you can’t specify more than one class name. (The class can implement multiple interfaces, but we’ll save that for another blog post.)<\/p>\n
To start with the simplest case, let’s create an empty subclass based on the Glass class. We’ll call it AnyGlass.<\/p>\n
PS C:\\> class AnyGlass : Glass {}<\/pre>\n
First, make sure that the class was created and that the base type is Glass.<\/p>\n
PS C:\\> [AnyGlass]\r\n\r\nIsPublic IsSerial Name     BaseType\r\n-------- -------- ----     --------\r\nTrue     False    AnyGlass Glass<\/pre>\n
Now, let’s create an AnyGlass object. There are several different ways to create an object<\/a> (“instantiate”) based on a class, but we’ll use New-Object here, because it’s so PowerShell.<\/p>\n
PS C:\\> $anyGlass = New-Object -TypeName AnyGlass\r\n\r\nPS C:\\> $anyGlass | Get-Member\r\n\r\nTypeName: AnyGlass\r\n\r\nName          MemberType     Definition\r\n----          ----------     ----------\r\nDrink         Method         bool Drink(int amount)\r\nEquals        Method         bool Equals(System.Object obj)\r\nFill          Method         bool Fill(int volume)\r\nGetHashCode   Method         int GetHashCode()\r\nGetType       Method         type GetType()\r\nToString      Method         string ToString()\r\nCurrentAmount Property       int CurrentAmount {get;set;}\r\nSize          Property       int Size {get;set;}<\/pre>\n
Notice that the AnyGlass object has the properties defined in the Glass class (Size, CurrentAmount), the methods defined in the Glass class (Drink, Fill), and the methods that the Glass class inherited from its base class, System.Object (Equals, GetHashCode, GetType, ToString).<\/p>\n
So, the AnyGlass class inherits from its parent and grandparent classes — its entire ancestry — just like people do.<\/p>\n
Add Members to a Subclass<\/h1>\n
A subclass can have properties and methods (and all types of members) that are not in the base class. For example, the Glass class has properties that are not in System.Object.<\/p>\n
I’ll add a Name property to the AnyGlass class.<\/p>\n
PS C:\\> class AnyGlass : Glass\r\n{\r\n    [String]$Name\r\n}\r\n\r\nPS C:\\> $anyGlass = New-Object AnyGlass\r\nPS C:\\> $anyGlass\r\n\r\nName Size CurrentAmount\r\n---- ---- -------------\r\n     0    0<\/pre>\n
You use inherited members in exactly the same way as you use members that are defined in the current class. In fact, unless you do some quick discovery, you really don’t know if a property or method is inherited or defined.<\/p>\n
PS C:\\> $anyGlass.Name = 'AnyGlass'\r\nPS C:\\> $anyGlass.Size = 6\r\nPS C:\\> $anyGlass\r\n\r\nName      Size   CurrentAmount\r\n----      ----   -------------\r\nAnyGlass  6      0<\/pre>\n
Also, inside the class, when you use $this to refer to the current object, you treat defined properties and inherited properties in the same way.<\/p>\n
class AnyGlass : Glass\r\n{\r\n    [String]$Name\r\n     \r\n    AnyGlass () {\r\n        $this.Size = 6\r\n        $this.CurrentAmount = 0\r\n        $this.Name = \"My glass\"\r\n    }\r\n}<\/pre>\n
Overloading Methods in the Base Class<\/h1>\n
You can have members that have the same name as a member in the base class, but take different parameters<\/i><\/b>. This is called an overloaded method<\/i>. In a subclass, it works the same way that it would if you had a method defined twice in the same class.<\/p>\n
For example, the Fill<\/b> method in the Glass class takes one integer argument that represents the volume added to the Glass.<\/p>\n
  + [Boolean] Fill ([int]$volume)<\/pre>\n
The Fill method in the AnyGlass takes the same volume integer argument and a string argument that represents a warning that it returns when you’ve overfilled the glass. (The Fill method in the base class has a predetermined warning.)<\/p>\n
class AnyGlass : Glass {\r\n\r\n\t# Methods\r\n\t[void] Fill ([int]$volume, [string]$Warning)\r\n\t{\r\n\t\tif ($this.currentAmount + $volume -le $this.Size)\r\n\t\t{\r\n\t\t\t$this.CurrentAmount += $volume\r\n\t\t}\r\n\t\telse\r\n\t\t{\r\n\t\t\tWrite-Warning $Warning\r\n\t\t}\r\n\t}\r\n}<\/pre>\n
When I pipe $AnyGlass to Get-Member and specify the Fill method, it tells me it has two overloads. It doesn’t mention (and doesn’t really care) which one is defined locally and which one is inherited.<\/p>\n
PS C:\\> $anyGlass | Get-Member -MemberType Method -Name Fill\r\n\r\nTypeName: AnyGlass\r\n\r\nName     MemberType     Definition\r\n----     ----------     ----------\r\nFill     Method         void Fill(int volume, string Warning), bool Fill(int volume)<\/pre>\n
When I call the Fill methods, they works exactly as they would if both Fill methods were defined in the same class. That is, the argument number and types determine which Fill method is called. I don’t need to do anything to call the Fill method of the Glass class, other than to provide only an integer.<\/p>\n
As a reminder, here’s the signature of each of the Fill methods:<\/p>\n
# In Glass\r\n+ [Boolean] Fill ([int]$volume)\r\n\r\n# In AnyGlass\r\n+ [void] Fill ([int]$volume, [string]$Warning)\r\n<\/pre>\n
If I call the Fill method with 2 arguments, an integer and a string, it calls the Fill method of the AnyGlass class, which when full, returns the warning string I specify.<\/p>\n
PS C:\\> $anyGlass.Fill(3, \"Oops! Too much\")\r\nWARNING: Oops! Too much<\/pre>\n
If I call the Fill method with 1 argument, an integer, it calls the Fill method of the Glass class, which has a predefined warning message that includes the room left in the glass. It also returns a Boolean value, $False, which indicates that the AnyGlass was not filled. Notice that I didn’t need to specify anything to get the inherited Glass method, because the AnyGlass class has both methods.<\/p>\n
PS C:\\> $anyGlass.Fill(3)\r\nWARNING: Sorry. The glass isn't big enough. You have room for 2.\r\nFalse<\/pre>\n
Overriding Methods of the Base Class<\/h1>\n
To hide a method in the base class, write a method that has the same arguments as the method in the parent class. That’s called overriding<\/i> a method. When methods have the same name and take arguments of the same type, the method in the subclass takes precedence, hides, or overrides<\/i> the method in the parent class.<\/p>\n
You can do the same thing with Properties.<\/p>\n
Here’s the AnyGlass class with a Fill method that takes just one argument, an integer, just like the Fill method in the Glass class.<\/p>\n
class AnyGlass : Glass {\r\n    # Methods\r\n    [void] Fill ([int]$volume)\r\n    {\r\n        if ($this.currentAmount + $volume -le $this.Size)\r\n        {\r\n            $this.CurrentAmount += $volume\r\n        }\r\n        else\r\n        {\r\n            Write-Warning \"Oops! Not enough room\"\r\n        }\r\n    }\r\n}<\/pre>\n
Notice that the signatures of the Fill methods are not identical. The Fill method of the Glass class returns a Boolean. The Fill method of the AnyGlass class returns nothing ([void]).<\/p>\n
# In Glass\r\n+ [Boolean] Fill ([int]$volume)\r\n\r\n# In AnyGlass\r\n+ [void] Fill ([int]$volume)<\/pre>\n
But, when I create an AnyGlass object and pipe it to Get-Method, it returns only one Fill method signature, instead of two. And, because the return type is Void, we know that it’s returning the Fill method of the AnyGlass class, which overrides the Fill method of the Glass class.<\/p>\n
PS C:\\> $anyGlass | Get-Member -MemberType Method -Name Fill\r\n\r\nTypeName: AnyGlass\r\n\r\nName     MemberType    Definition\r\n----     ----------    ----------\r\nFill     Method        void Fill(int volume)<\/pre>\n
When I call the Fill method with a volume, it calls the local Fill method.<\/p>\n
PS C:\\> $anyGlass.Fill(1)\r\nPS C:\\> $anyGlass.Fill(1)\r\nPS C:\\> $anyGlass.Fill(1)\r\nWARNING: Oops! Not enough room.\r\nPS C:\\><\/pre>\n
When a subclass overrides a base class, does it completely hide the parent class? Happily, no!<\/p>\n
Calling a member of a base class<\/h1>\n
Even when a base class member is hidden by a subclass member, you can still call the base class member on an instance of the subclass.<\/p>\n
Here’s the syntax:<\/p>\n
([baseClass]$instance).member<\/pre>\n
Essentially, you cast the object to the base class, enclose the casted object in parentheses to make sure it’s evaluated first, and then call the member in the usual way. For example, to call the Fill method of the Glass<\/b> class on an AnyGlass object:<\/p>\n
PS C:\\> ([Glass]$anyGlass).Fill(4)\r\nWARNING: Sorry. The glass isn't big enough. You have room for 2.\r\nFalse<\/pre>\n
In the script for a class, you can use the same syntax to modify the $this variable that refers to the current object.<\/p>\n
For example, in my WineGlass class<\/a>, the Fill method of the WineGlass class calls the Fill method of the Glass class, which updates the CurrentAmount property. Then, the Fill method of the WineGlass class updates a local property, TotalPoured.<\/p>\n
[void] Fill ([int]$volume)\r\n{\r\n    if (([Glass]$this).Fill($volume))\r\n    {\r\n        $this.TotalPoured += $volume\r\n    }\r\n}<\/pre>\n
You can also call all the way back to our common ancestor, System.Object. For example, if I add a ToString method to the AnyGlass or Glass class, I can call it. Or, I can call the ToString method on System.Object.<\/p>\n
PS C:\\> $anyGlass = [AnyGlass]::New()\r\nPS C:\\> $anyGlass.Size = 6\r\nPS C:\\> $anyGlass.CurrentAmount = 4\r\n\r\nPS C:\\> $anyGlass.ToString()\r\nA 6-ounce glass with 4 ounces.\r\n\r\nPS C:\\> ([System.Object]$anyGlass).ToString()\r\nAnyGlass<\/pre>\n
Constructors are not inherited<\/h1>\n
When I talked about inheritance, I was careful not to say that “all” members, or all properties and methods, are inherited. Constructors<\/a>, which are really just special methods, are not inherited. Instead, like all PowerShell classes, the new class is created with a default (parameter-less) constructor.<\/p>\n
(Need help with constructors? See: Why do we need constructors?<\/a>)<\/p>\n
To find the constructors of a class, use the New<\/b> static property that PowerShell adds to all classes. (Be sure to use the property, with no parentheses, not the method, with parentheses, which creates a new object).<\/p>\n
This command shows that the Glass class has two constructors; a default constructor and a constructor that takes two integers; the first for the size and the second for the amount.<\/p>\n
PS C:\\> [Glass]::New\r\n\r\nOverloadDefinitions\r\n-------------------\r\nGlass new()\r\nGlass new(int Size, int Amount)<\/pre>\n
But the AnyGlass class just has the default constructor that is added automatically to all PowerShell classes.<\/p>\n
PS C:\\> [AnyGlass]::New\r\n\r\nOverloadDefinitions\r\n-------------------\r\nAnyGlass new()<\/pre>\n
You can add constructors to the subclass as you would to any class. Remember, that when you add a constructor to the class, it replaces<\/b> the automatic default constructor. So, if you want a default constructor on your class, you need to add it explicitly.<\/p>\n
Calling a base class constructor<\/h1>\n
The last piece of the inheritance puzzle is calling the constructor of the base class.<\/p>\n
(Need help with constructors? See: Why do we need constructors?)<\/a><\/p>\n
Here’s the scenario. The base class defines a constructor that takes property values as arguments and assigns each value to the correct property. The Glass class is intentionally simple, but it can get complex when the class defines many properties, or the arguments are used to calculate property values.<\/p>\n
Glass ([int]$Size, [int]$Amount)\r\n{\r\n    $this.Size = $Size\r\n    $this.CurrentAmount = $Amount\r\n}<\/pre>\n
In the subclass, you could easily define a corresponding constructor, such as:<\/p>\n
AnyGlass ([int]$Size, [int]$Amount)\r\n{\r\n    $this.Size = $Size\r\n    $this.CurrentAmount = $Amount\r\n}<\/pre>\n
But, you’re maintaining virtually the same code twice. Instead, you can call the base class constructor from the subclass.<\/p>\n
The syntax, which uses the base<\/b> keyword, is:<\/p>\n
 Subclass (arguments) : base (argumentsToBaseClassConstructor) { ... }<\/pre>\n
For example, this AnyGlass constructor calls the Glass class constructor. In this case, there’s no logic in the constructor (inside the script block), but it’s permitted if you need it.<\/p>\n
AnyGlass ([int]$Size, [int]$Amount) : base($Size, $Amount) { }<\/pre>\n
The arguments and their types can be different, just so the call to the base class constructor provides the arguments it requires. For example, this AnyGlass constructor creates a full AnyGlass (Size -eq CurrentAmount) every time.<\/p>\n
AnyGlass ([int]$Amount) : base($Amount, $Amount) { }<\/pre>\n
However, when creating an instance of a subclass, you cannot call the constructor of a base class. It’s explicitly prohibited<\/a>, because it’s error prone.<\/p>\n
You can’t inherit from that (it’s sealed)<\/h1>\n
Now, a few limits to all of this power.<\/p>\n
You can’t create a subclass based on any class; only classes that are not sealed<\/i>. The sealed<\/a><\/i> keyword in C# creates a class that you cannot use as a base class.<\/p>\n
\"Screenshot<\/a><\/p>\n
Programmers use sealed<\/i> when they want to protect the interface from development that they cannot control. They don’t want to be responsible for someone’s bad implementation or any side effects it might have. They’d rather weather a bit of anger from a stymied programmer than a pile of bugs in code they don’t own. (Many thanks to Doug Finke, Kevin Ilsen, Adam Driscoll, Lee Holmes, Rodney Stewart, Eric Slesar, and David J. Brown for their insights on this topic.)<\/p>\n
\"clip_image004\"<\/a><\/p>\n
As an aside, the opposite of sealed<\/i>, well sort of, is abstract<\/i>, which indicates that a class is designed only<\/b> to be a base class for other subclasses. You can’t create an instance of an abstract class (e.g. New-Object or [<Class>}::New() ), but you can create subclasses.<\/p>\n
Most .NET classes are sealed, but the PowerShell classes that you create are not sealed (and the sealed keyword is not valid), so you can use any PowerShell class as a base class. And, you can use .NET classes that are not sealed, such as KeyedCollection<\/a>, which is an abstract base class.<\/p>\n
You can’t inherit from that either (no default constructor)<\/h1>\n
In Windows PowerShell 5.0.10586.122 classes, you cannot inherit from a class that does not have a default constructor<\/a> (a constructor with no parameters), unless you explicitly define a default constructor in the subclass.<\/p>\n
\u00a0<\/a>\"Screenshot<\/a><\/p>\n
According to Jason Shirk on the PowerShell Team, it’s a bug, but it’s not yet fixed<\/a>.<\/p>\n
When it’s fixed, you’ll be able to base a class on a class that has no default constructor, but the derived class constructor must call a constructor in the base class, just like in C#.<\/p>\n
That just about wraps it up. Thanks to Jason Shirk, Sergei Vorobev, and many others on Twitter and the PowerShell Facebook group for their help with this post.<\/p>\n
June Blender is a technology evangelist at SAPIEN Technologies, Inc. You can reach her at juneb@sapien.com<\/a> or follow her on Twitter at @juneb_get_help<\/a>.<\/i><\/p>\n","protected":false},"excerpt":{"rendered":"
If you’re learning about classes in Windows PowerShell 5.0, one of the first new concepts that you’ll encounter is inheritance. When you create a class that is based on another class, your new subclass or child class automatically gets the inheritable members (e.g. properties and methods) of the parent class or base class. Inheritance is […]<\/p>\n","protected":false},"author":31,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1033,941,1090,25],"tags":[934,28,961,1084,997,1085,1086],"class_list":["post-11594","post","type-post","status-publish","format-standard","hentry","category-classes-in-powershell-5-0","category-powershell-5-0","category-powershell-5-0-10586-122","category-windows-powershell","tag-juneb","tag-powershell","tag-powershell-5-0","tag-powershell-classes","tag-windows-powershell","tag-windows-powershell-5-0","tag-windows-powershell-classes"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/11594","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/users\/31"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/comments?post=11594"}],"version-history":[{"count":41,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/11594\/revisions"}],"predecessor-version":[{"id":11663,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/11594\/revisions\/11663"}],"wp:attachment":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/media?parent=11594"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/categories?post=11594"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/tags?post=11594"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}