This Is My Ball of Mud
In college I wrote a solution for the Knight’s Tour. Since then I’ve planned to build a full chess program for playing chess games (not to be confused with a chess engine, which is more like an artificial intelligence that plots and plans chess moves). Not only did I want to build a chess game, but I wanted to use it as an experiment to test what I’ve learned about object-oriented design. I’ve made a few trial runs at it over the last few months, but always hit a design wall. Every few weeks I pick it up again and eventually hit a wall that stops me dead in my tracks. I’ve rebuilt the project from scratch about ten times now. Picking it up again recently, I decided this time I’m going to build this damn thing once and for all. Guess what happened? Wall. All these walls are starting to look like a castle, and I don’t mean the fun bouncy kind. Continue reading
“Education is what remains after one has forgotten what one has learned in school.”
What have I learned about programming, and OOP in general?
One of the biggest eye-openers is very simple. An idea that can easily get lost when using high level languages or discussing the philosophy of what’s right and wrong in programming. It’s also lost on anyone who doesn’t study computer science in school and only programming (/raisehand). Just like we don’t consciously think about tying our shoes, we don’t always think about the intricate roots of programming when we’re doing it.
The idea is that math is the basis for programming, and follows much of the same rules of mathematics. Math and programming both share certain protocols for operating on data sets. Those protocols include things like inputs, outputs, domains, ranges, abstractions, and functions. I’m no math whiz, but I’ll do my best to explain what I mean. Continue reading
What’s Going on Here?
Object-oriented programming concepts are almost universally problematic for new programmers (including myself). It’s easy enough to find information about these concepts, but my understanding of them always feels incomplete. If you search the Internet you’ll find lots of guidelines to correctly structure and write object-oriented code. There are also various concepts that are important to understand like abstraction, and encapsulation, etc. You’ve probably heard them all by now. If you haven’t heard of these concepts, then get a book on object-oriented programming. My goal is not to explain what’s already been explained elsewhere in great detail. My goal is to try to offer my perspectives on what I learn in order to help programmers on the same path avoid long periods of confusion and frustration. One of the things I hope to do here is analyze my own projects and show why I make specific design choices, what concepts and guidelines do I consider when making my choices, and what my alternative choices are and why I didn’t choose them. Continue reading