Ok, today was fun! It was one of those happy days where I think things clicked as opposed to all those frustrating days where time is lost and nothing is accomplished.
I re-did the business rules of ttt. I know, i know… I started over again?! Not completely. There was a lot going on in my original “play-game” namespace, so I needed a new space to collect my thoughts and think about what the game, and only the game, need in order to play a simple game of ttt.
Early this morning, i looked at my blog from yesterday to remind myself of what I was supposed to do today to help with my time management, and recalled that I needed to watch the video on the DIP. I did this. Things kind of made sense, but I still didn’t understand the application of the principle. Later when I went to work on my presentation for the DIP, i found a blog posted by my dad called “A Little Architecture” that spelled it out in a conversational, teacher to student kind of way. I was able to relate to a line in this post that read:
“The important decisions that a Software Architect makes are the ones that allow you to NOT make the decisions about the database, and the webserver, and the frameworks.”
This was true in my previous line of work also. The important decisions that I made on a daily basis were the ones that allowed my operators to make the, while still very important decisions, the lower level decisions to be successful at their job–my decisions were often what saved me from the 2AM phone calls also. In any case, I’ve known many managers to fail at their jobs by making those level decisions for the operators. I can tell you, if you want to piss off an operator, tell him how to do his job!
So then I began working on my presentation and trying to think of a good example. There was one on the tip of my mind that I felt was a background memory from recently, and it took me a minute to reach. Aha! It was this past weekend! While I was working in the sun-room, Keith and the boys were watching “Wreck It Ralph: Ralph Breaks The Internet”.
There was a recurring message in the movie to warn game-characters that if they died in a game that was not their own, they would die forever and not be regenerated. This makes sense, right? If there’s not an instance of an object in the application, it will make a new instance. But furthermore, if a character dies in another game, that character’s game does not die, it goes about like nothing happened. The game does not care about the character playing, it only cares that there is a character playing. Can you imagine a game where, if you die, the game dies too?! In other words, where the game is dependent upon the player or character choice or that the trees in the field are green? No one would buy that game! What if you had to buy a new console every time you wanted to try a new game (i’m picturing super nintendo btw, just so we are on the same page)?
Alright, enough about that. That was just to show that it got me thinking, so when i went back to ttt this afternoon, i started with a new namespace called, “the-game”, and I asked myself, “what does the simplest form of the game of ttt require in order to work?”. It requires a board and 2 players, but it doesn’t care about the size of the board or the format of the board and it doesn’t care if there is differentiation between the types of the 2 players.
Ok. So i wrote that. From the tests, i fed it what it required, and made it all pass. I even got my terminal-gui to have it’s own defmethod to play based on the multimethod of “the-game”, and got it do exactly what I wanted it to do. So, i think it works. I’m not done, but i think i get it–maybe. Who knows, i might get back at it tomorrow and have none of it make sense again, but for now, i think it clicked.