Eric Normand Courses/A02 Data Modeling in Clojure

The key to good software is finding a great way to model the problem

In Clojure, the common advice is "just use a map". There's some truth to that, but it's obviously more complicated. Clojure gives you lots of ways to model a problem. You can use:
  • maps
  • vectors
  • sets
  • functions
  • strings
  • keywords
  • etc.
The truth is that choosing the right way to model the problem requires design decisions. Lots of tradeoffs. And lots of iteration. You might not get it right the first time. But you want to keep iterating until you get a tight fit between the structure of the problem and the structure of your code.

Each representation has limitations and tradeoffs. You want to find the limitations that help guide you to success and the tradeoffs you can live with. The hard truth is that it takes lots of experience to be able to do it quickly. But there's no magic to it.

  • $48

A02 Data Modeling in Clojure

  • Closed

In this course, I give you a peek behind the curtain. I work step-by-step through different iterations of a domain model, discussing what I'm thinking, why I'm trying something else. We model the game of solitaire, a card game we're all familiar with.
  • How do you represent cards? The suit? The value?
  • How to represent a deck of cards?
  • What about the current state of a board?
  • Can we represent a move?
This is a deep dive into the making of a domain representation. You'll be surprised how many options there are.

  • $48

A02 Data Modeling in Clojure

  • Closed

Contents

Introduction
Card Representations
Card functional abstraction
Modeling Games
Moves Part 1
Moves Part 2
Moves Part 3
Dealing a Game
Validating moves

  • $48

A02 Data Modeling in Clojure

  • Closed