In my last blog post, I introduced you to using .NET named pipes to implement BlackJack across different PowerShell processes and even across the network. In this blog post, we will take a look at what it is like to convert the previous procedural implementation to an object-oriented implementation using the class support in the preview version of Windows PowerShell 5.0 – specifically the version in the Windows 10 Technical Preview. Note: “preview” version means that the classes feature is likely to change between now and when PowerShell 5.0 ships. Hopefully that means it gets better but there is always the possibility the feature gets pulled.
One of the major benefits of object-oriented programming is encapsulation i.e. you can put related code and state together into a single class definition rather than have it spread across your source code. This makes it easier to fix bugs because certain types of bugs tend to impact all code that touches a specific data structure. In procedural code you tend to look all over for that code but in an object-oriented implementation the code tends to be within the same class definition. Here’s an example from the “procedural” version of the BlackJackDealer script. These are the variables and functions that deal with cards, the deck and the hand:
$suits = 'Clubs','Diamonds','Hearts','Spades'
$ranks = 'Ace','2','3','4','5','6','7','8','9','10','Jack','Queen','King'
function GetShuffledDeck {
$deck = 0..3 | Foreach {$suit = $_; 0..12 | Foreach {
$num = if ($_ -eq 0) {11} elseif ($_ -ge 10) {10} else {$_ + 1}
[pscustomobject]@{Suit=$suits[$suit];Rank=$ranks[$_];Value=$num}}
}
for($i = $deck.Length - 1; $i -gt 0; --$i) {
$rndNdx = Get-Random -Maximum ($i+1)
$temp = $deck[$i]
$deck[$i] = $deck[$rndNdx]
$deck[$rndNdx] = $temp
}
$deck
}
function GetValueOfHand($hand) {
$sum = ($hand | Measure-Object Value -Sum).Sum
if ($sum -gt 21) {
$sum = ($hand | Foreach {if ($_.Value -eq 11) {1} else {$_.Value}} | Measure-Object -Sum).Sum
}
$sum
}
function IsHandBust($hand) {
(GetValueOfHand $hand) -gt 21
}
function IsHandBlackJack($hand) {
if ($hand.Length -ne 2) { return $false }
(GetValueOfHand $hand) -eq 21
}
function DumpHand($hand) {
$cards = $hand | Foreach {DumpCard $_}
$OFS = ', '
"$cards"
}
function DumpCard($card) {
"$($card.Rank) of $($card.Suit)"
}
$cardNdx = -1
$deck
function DealCard {
if ($cardNdx -lt 0) {
WriteToPipeAndLog 'Deck empty, reshuffling deck' > $null
$script:deck = GetShuffledDeck
$script:cardNdx = $deck.Length - 1
}
$deck[$script:cardNdx--]
}
Note the script level variables $suits, $ranks and $cardNdx. With functions you have to be careful to remember to use script scope when you need to modify a script scope variable e.g.:
$deck[$script:cardNdx--]
It’s easy to forget to use the $script: prefix and that can lead to hard to find bugs. It’s also not so obvious which of these functions are using the script scope variables. Sure you can use your editor’s Find feature to determine that but in more complex cases involving multiple dot-sourced scripts, using Find can be more challenging. Ideally you’d like to have the variables with the functions that use those variables encapsulated together.
BTW modules provide encapsulation and at this point in time, modules provide better support for encapsulation than PowerShell classes do. That is, variables in modules default to private but can be made public. In PowerShell classes, the equivalent is a property but unfortunately at this time, properties can only be public. But since this post is about classes and not modules, let’s press on.
Let’s look at the equivalent implementation using classes (and an enum).
# Updated for Windows 10 Preview Build 9879 - new 'hidden' keyword
# and added support for semi-colon separated enum fields.
enum Suit { Clubs; Diamonds; Hearts; Spades }
class Card {
[Suit]$Suit
[string]$Rank
[int]$Value
Card($s, $r, $v) {
$Suit = $s
$Rank = $r
$Value = $v
}
[string] ToString() {
return "$Rank of $Suit"
}
}
class Deck {
hidden [Card[]]$Cards
hidden [Pipe] $Pipe
hidden [int]$Index
Deck([Pipe]$p) {
$this.Index = 0
$ranks = 'Ace','2','3','4','5','6','7','8','9','10','Jack','Queen','King'
$this.Cards = 0..3 | Foreach { $suit = $_; 0..12 | Foreach {
$num = if ($_ -eq 0) {11} elseif ($_ -ge 10) {10} else {$_ + 1}
[Card]::new([Suit]$suit, $ranks[$_], $num)
}
}
$this.Shuffle()
$this.Pipe = $p
}
[void] Shuffle() {
for($i = $this.Cards.Length - 1; $i -gt 0; --$i) {
$rndNdx = Get-Random -Maximum ($i+1)
$temp = $this.Cards[$i]
$this.Cards[$i] = $this.Cards[$rndNdx]
$this.Cards[$rndNdx] = $temp
}
}
[Card] DrawCard() {
if ($this.Index -gt $this.Cards.Length - 1) {
$this.Shuffle()
$this.Index = 0
Write-Host ($this.Pipe.WriteLine('Deck empty, reshuffling deck'))
}
return $this.Cards[$this.Index++]
}
[string] ToString() {
$OFS = ', '
return "$Cards"
}
}
class Hand {
hidden [Deck]$Deck
hidden [Card[]]$Cards
Hand([Deck]$d) {
$this.Deck = $d
$this.Cards = $d.DrawCard(), $d.DrawCard()
}
[Card] DrawCard() {
$card = $Deck.DrawCard()
$this.Cards += $card
return $card
}
[int] GetValueOfHand() {
$sum = ($Cards | Measure-Object Value -Sum).Sum
for ($i = $Cards.Length - 1; ($i -ge 0) -and ($sum -gt 21); $i--) {
if ($Cards[$i].Value -eq 11) {
$Cards[$i].Value = 1
$sum -= 10
}
}
return $sum
}
[string] ToString() {
$OFS = ', '
return "$Cards"
}
[string] ToDealerString() {
return $this.Cards[0].ToString() + ', hole card'
}
[bool] IsBlackJack() {
if ($this.Cards.Length -ne 2) { return $false }
return $this.GetValueOfHand() -eq 21
}
[bool] IsBusted() {
return $this.GetValueOfHand() -gt 21
}
[bool] IsMandatoryDealerHit() {
return $this.GetValueOfHand() -lt 17
}
}
A couple of things to note here. First, yes the object-oriented version is more lines of script. However, more lines of script doesn’t always mean more complex or harder to maintain. In fact, I’d argue just the opposite in this case. The script is easier to understand from a perspective of what variables are impacted by what methods. We can easily see we have three basic types here: Card, Deck and Hand. Each type knows how to perform the operations required of it i.e. a Deck knows how to shuffle, a Hand knows how to draw a Card from the Deck, a Card knows its value, etc.
Note the enum definition for Suit. At this point in time, it requires newline as a separator between enum fields. That makes this definition of Suit take more lines than in my original version. UPDATE 11/15/2014: I would love to see the team add support for comma as a separator which would tighten up this definition to: Ask and you shall receive. 🙂 There is now semi-colon separator support for enum fields. The following works on PowerShell in build 9879 of the Windows 10 Technical Preview.
enum Suit {Clubs;Diamonds;Hearts;Spades} # in build >= 5.0.9879
The second thing to note is that none of the “methods” use the function keyword. They are sans any keywords like function or def. Just a return type (or [void] for no return type), the method name and the parameters. Nice and succinct.
The third and probably most important difference to note is that every method that has a return value *must* use the return keyword. This is a major difference from typical PowerShell functions. In functions, any output that is not captured or redirected is streamed back to the caller. In this regard, copying script from the command line and pasting it into a function doesn’t result in any behavioral differences. All command output that isn’t captured in a variable or redirected is “output” from the function. Class methods however, act more like traditional programming language methods. They do not automatically stream output back to the caller. So in a class method, you have to explicitly return the data from the method using the return keyword.
Another thing worth noting is how instances of your class get rendered. Right now, sending an instance of a class to a Format-* command (or Out-Default by default) will result in the object either having its properties displayed – just like this was a PSCustomObject. Or if there are no properties, just the class name gets displayed. Inside of a double-quoted string e.g. “$hand”, the class name is displayed. However, you can change this behavior by implementing a ToString() method in your class e.g.:
[string] ToString() { return '...Whatever makes sense...' }
You can see that I have done this for the Card, Deck and Hand classes.
I also want to show you the Pipe class:
# The hidden keyword is new to builds >= 5.0.9879 and hides the associated
# fields for development (Intellisense) purposes.
class Pipe {
hidden $PipeServer
hidden $PipeReader
hidden $PipeWriter
Pipe() {
$PipeServer = new-object IO.Pipes.NamedPipeServerStream('BlackJack',
[System.IO.Pipes.PipeDirection]::InOut)
$PipeReader = new-object IO.StreamReader($PipeServer)
$PipeWriter = new-object IO.StreamWriter($PipeServer)
}
[void] Dispose() {
$this.PipeServer.Dispose()
}
[void] WaitForConnection() {
$PipeServer.WaitForConnection()
$PipeWriter.AutoFlush = $true
}
[string] ReadLine() {
return $PipeReader.ReadLine()
}
[string] WriteLine([string]$msg) {
$PipeWriter.WriteLine($msg)
return $msg
}
}
Note how it wraps up the StreamReader and StreamWriter as internal variables.
One feature I really want to see added to PowerShell classes is support for at least a private access modifier. Like modules, I want to make many of my class properties visible only from inside the class. And to a lesser extent I want to do that for some methods as well. UPDATE 11/15/2014: I have been informed that having a true “private” modifier would make the debug experience bad. The team has come up with a compromise via a new keyword – hidden. This effectively tells the Intellisense feature to not display the class member when an instance of the class is being accesed from “outside” the class. You will still get Intellisense of these members from within the class. And when you are debugging you will be able to see the hidden fields. That seems reasonable to me.
The nice thing about the code above is that the user of this Pipe class doesn’t have to deal with individual $PipeServer, $PipeReader or $PipeWriter objects, they just use the instance of this class – $pipe that is created in the main body of this script (see below) using the static new() method. Using the new() method is how you create instances of your classes. Note that class constructors can take parameters. You can see this below in the call to the [Deck] constructor where I pass it the $pipe variable. Here is the *complete* main body of the dealer script that uses classes:
$pipe = [Pipe]::new()
$deck = [Deck]::new($pipe)
$blackJackGame = [BlackJackGame]::new($pipe, $deck)
$blackJackGame.StartGameLoop()
Pretty simple eh? Most of the game logic has been encapsulated in the BlackJackGame class. Here are links to the full implementations of BlackJackDealer with Class.ps1 and BlackJackPlayer with Class.ps1.
For more information on using classes in PowerShell V5, check out Dan Harman’s talk on this topic at the European PowerShell 2014 Summit.
Keith Hill's Blog 