Indy Code - Taking a Gamble With F#: Implementing Blackjack
Download as PPTX, PDF1 like764 views
The document discusses the implementation of a blackjack game using F#, detailing the various data types such as tuples, records, collections, and discriminated unions. It outlines how to model game elements like decks, players, and actions while emphasizing type safety and domain modeling. Additionally, it covers error handling and function failure management using the maybe pattern in functional programming.
Indy Code - Taking a Gamble With F#: Implementing Blackjack
- 1. Taking a Gamble with F# Implementing Blackjack Cameron Presley @PCameronPresley http://Blog.TheSoftwareMentor.com
- 2. Little About Myself Senior Software Engineer at Pilot/Flying J Musician and Board gamer Co-organizer of @FunctionalKnox “Developer Betterer”
- 3. Goals Explore the different types in F# and the when to use them Demonstrate how to use these types to model Blackjack Show how to deal with things that can fail
- 4. Types Overview How to hold data Collections Combining different types as one
- 5. Know When to Hold Them Holding Data Source
- 6. Holding Data Tuples Provides a way to model all possible combinations of types A tuple of int*string would represent all combinations of integer and strings A triple of int*string*int would represent all combinations of integer, string, and integer
- 8. Holding Data Tuples Advantages Create on the fly Easy to break down Disadvantages Parameters have to be in order (int*string is different from string*int) Hard to keep values in the right order (int*int*int) Doesn’t provide a lot of type safety
- 10. Holding Data Tuples When Should You Use Tuples? When working within a function When there are few parameters When Should You NOT Use Tuples? Representing a domain model Need more type safety Representing the same data types (i.e. int*int*int) Can be hard to remember which element represents which
- 11. Holding Data Records Like a tuple, provides a way to model all possible combinations of a value Key Differences Must define as a type Provides labels (i.e. dot syntax) Order doesn’t matter
- 13. Holding Data Records Advantages Order doesn’t matter Named parameters Easy to retrieve a value Disadvantages Can’t create on the fly Verbose definition
- 14. Holding Data Records When Should You Use Records? Representing domain models Working with a lot of parameters Providing better type safety When Should You NOT Use Records? Intermediate results for a function
- 15. Holding Data Review Tuples Create on the fly Easy to break down into separate values Records Representing domain models Working with a lot of parameters Providing better type safety
- 16. Collections
- 17. Collections Sequences Provides a way to define the collection by using a generator function Lazy by default Only creates values when iterated Similar to IEnumerable from C#
- 19. Collections Sequences Advantages Can model an infinite collection Provides a way to generate all values Only computes values when needed Disadvantages Expensive to add a value -> O(n) Retrieving an item by index is slow -> O(n) Can’t modify elements in place
- 20. Collections Lists Represents a collection as two parts, the first element, and the rest of the list First element referred to as the head Rest of the list is referred to as tail Similar to linked lists Typically used with recursion, pattern matching, and the :: (cons) operator
- 22. Collections Lists Advantages Can define recursive functions to process element by element Adding additional elements is fast -> O(1) Can be defined with a generator function Disadvantages Can’t model infinite series Indexing to an element is slow -> O(n) Can’t modify elements in place
- 23. Collections Arrays Represents a collection as a dictionary such that the index finds the value Long story short, similar to arrays in other languages Typically used when lookup speed matters
- 25. Collections Arrays Advantages Quick lookup -> O(1) Can change one element in the array with a different element -> O(1) Can model multidimensional data (2D arrays) Disadvantages Can’t model infinite series Adding additional elements is slow -> O(n)
- 26. Collections Summary Sequences IEnumerable from C# Should use when all values can be generated by a function or when modeling an infinite series Lists Linked lists Great for when the number of elements can change or when processing element by element Arrays Similar to traditional arrays Best used when certain elements need to change or for quick access
- 27. Combining Different Types Discriminated Unions
- 28. Combining Different Types Discriminated Unions Discriminated Unions provides a way to specify that a type can be one of many different types The Difference between Tuples/Records and Discriminated Unions (DUs) Tuples/Records -> int*string (all combinations of integer and string) DUs -> int | string (either it’s an integer or a string) Typically used with pattern matching
- 29. Combining Different Types Discriminated Unions
- 30. Combining Different Types Discriminated Unions
- 31. Combining Different Types Discriminated Unions
- 32. Combining Different Types Discriminated Unions Now I needed to create a new coordinate and I do this: What’s to stop me from making this error?
- 33. Combining Different Types Discriminated Unions Problem is that Lat and Long are part of the domain for Coordinate Instead of modeling them as floats, they should have their own type But float is the correct data type, so how I create a type that wraps around a float? Single Case Discriminated Unions!
- 34. Combining Different Types Discriminated Unions
- 35. Combining Different Types Discriminated Unions When a primitive needs to be modeled as part of the domain Single Case When different type signatures actually model the same thing Combining different types When there are a finite number of possibilities Enum Style
- 36. Data Type Recap Holding Data Tuples, Records Collections Sequences, Lists, Arrays Combining Different Types Discriminated Unions
- 38. Modeling The Domain Goals Identify the different models Implementation
- 39. Modeling The Domain Goals Has to be easy to read and understand Easier to maintain Defines a ubiquitous language Provides a way for developers, QA, and users to communicate Make illegal states unrepresentable Why allow bad data to be created?
- 40. Identifying Models Usually start big and then break down to smaller pieces How do we represent the entire game? Define a Game type
- 42. Identifying Models What’s included in a game? Game has Deck Players Dealer
- 45. Identifying Models What’s a Deck? Represents all of the Cards that will be used in the Game What’s a Card? Combination of Rank and Suit What’s a Rank One of 13 possible values A, 2, 3, 4, 5, 6, 7, 8, 9, 10, J, Q, K What’s a Suit One of 4 possible values Hearts, Clubs, Spades, Diamonds
- 48. Identifying Models What are Players? Collection of Player What’s a Player Someone playing against the Dealer Has both a Hand and a Status What’s a Hand? Represent the Cards a Player has
- 50. Identifying Models Represents the state of the Player Blackjack -> 2 cards worth with 21 Busted -> Has a Score over 21 Stayed -> Not Blackjack and a Score of 21 or less Cards Dealt -> Hasn’t taken a turn yet
- 52. Identifying Models Represents the final result of a Player’s Hand Result is based on whether the Player Busted or Stayed Can only be of one value (integer) Important to know when comparing who won
- 54. Identifying Models Competes against every Player Similar to Player Dealer has a Hand and a Status Unlike Player, there’s only one, so no ID is needed
- 56. Identifying Models Talked about the components of the game What about points? What about the actions that a player can take?
- 58. Identifying Models Cards are worth Points based on their Rank Face cards are worth 10 points Point cards are worth that many (2’s worth 2, 3’s worth 3 …, 10’s worth 10) Aces can be counted as 1 or 11
- 60. Identifying Models During the game, a participant can take one of two different actions Draw Cards (Hit) Adds a single card to their Hand Stay Stops drawing cards
- 62. Implementing the Domain We’ve broken down the domain into smaller pieces and identified dependencies amongst the pieces Time to implement the pieces in a bottom-up order
- 65. Implementing the Models Rank Can be one of 13 possible values A, 2, 3, 4, 5, 6, 7, 8, 9, 10, J, Q, K What type is great for modeling a finite set of values?
- 67. Implementing the Models Suit Can be one of 4 possible values Hearts, Clubs, Spades, Diamonds How should we model this?
- 69. Implementing the Models Card Contains both a Rank and Suit What type is great for holding data?
- 71. Implementing the Models Deck Contains 1 or more Cards What are some properties of a Deck? Length will change throughout the game Which collection type should we use to model this?
- 73. Implementing the Models Hand Contains the Cards for a Player Initially starts with two cards, but can draw more during the game How should we model this?
- 75. Implementing the Models Score Represents the final value of a Hand Can only be one value (integer) What’s a way to wrap primitives as their own type?
- 77. Implementing the Models Status Blackjack Player has two cards and their score is 21 Busted Player went over 21 and that’s their final score Stayed Player decided to not take any more Cards and that’s their final score Cards Dealt Player hasn’t taken their turn
- 78. Implementing the Models Status Can be one of a finite number of choices Some of the type require Score and other ones don’t How should we model this?
- 80. Implementing the Models Dealer A Dealer contains Hand Status How should we model this?
- 82. Implementing the Models Player A Player contains Hand Status ID How should we model this?
- 84. Implementing the Models Players Represents all the players in the Game Number of Players won’t change during the game Each player must finish their turn before the next player can start Which collection type should we use?
- 86. Implementing the Models Game Contains Deck Players Dealer How should we model this?
- 88. Implementing the Models Points Every Card is worth a value based on the Rank One of two possible values Aces can be worth 1 or 11 Everything else can be worth one value Need to combine two different types as one, how should we model this?
- 90. Implementing the Models Actions Represents what a participant can do during the Game One of two possible values Hit Stay Finite number of choices, how to model?
- 93. Implementing the Models Summary Determined the models by using domain terms (ubiquitous language) Started with the biggest model (Game) and broke it down into smaller pieces and then repeating the process with the smaller pieces After finding the models, implemented the models in a bottom-up fashion Able to define the domain in a way such that bad states are unrepresentable
- 94. Playing the Game
- 95. Playing the Game Sometimes, pure functions can fail How can we handle this? We’ll look at Drawing a Card Setting up a Player
- 96. Playing the Game Drawing a Card Throughout the course of the Game, Cards will be drawn from the Deck Let’s create a function, drawCard that takes a Deck as input and returns the top Card and the rest of the Deck as output
- 97. Drawing a Card Are there any issues with this implementation? What about an empty deck? Match Failure Exception -> The match cases were incomplete How can we model a type that may have a value or not?
- 98. Playing the Game Drawing a Card Introducing the Option type! Special kind of Discriminated Union that handles when there’s a value and when there isn’t. Let’s rewrite the drawCard function to handle an empty deck
- 99. Playing the Game Drawing a Card
- 100. Playing the Game Setting up a Player Now that we have a way to draw cards, we can now setup a Player Remember that a Player starts off with a Hand of two cards and a Status of CardsDealt
- 101. Playing the Game Setting up a Player Remember, drawCard returns an option, so we need to handle that.
- 102. Playing the Game Setting up a Player This code is not nearly as readable as the first solution What are we really trying to accomplish? Try to draw two cards, if so, return Some Player, otherwise, None Wouldn’t it be nice if we could have the short-circuit logic of the second solution, but still have the readability of the happy path? How can we work around all the pattern matching?
- 103. Playing the Game Setting up a Player By using the Maybe Builder pattern! Known in other FP languages as Maybe. Two parts Provides a way to short-circuit logic if the input is None (called Bind) A way to wrap a value as an option (called Return)
- 104. Playing the Game Setting up a Player
- 105. Playing the Game Setting up a Player
- 107. Playing the Game Setting up a Player Problem Creating a Player can fail because there’s not enough cards Putting in the error handling code makes it cluttered and hard to read Solution Using the Maybe pattern, we can short-circuit our function flow to return None before calling anything else When to Use Lots of nested pattern matching on options
- 108. Wrapping Up Overview of the different F# types and the advantages of each Modeled and implemented the domain for Blackjack using the different types Explored how to handle functions that can fail
- 109. Additional Resources Learning more about F# F# for Fun and Profit -> http://fsharpforfunandprofit.com/ Code Solution Blackjack Repo -> https://github.com/cameronpresley/Blackjack How to find me Twitter ->@pcameronpresley Blog -> http://blog.thesoftwarementor.com