After taking a kind of quick course in some of the finer points of OO programming, I’ve come back to the design patterns book I had my mom buy for me recently.
It’s this one:
(Clicking the image will take you to its Amazon page, where you can buy it for yourself if you want.)
Oh, a note before you do that, though. All the code examples are in Java, so you need to either be reasonably familiar with Java and its syntax, or with a similar language like C++ or C#. Although, quite honestly, if you’re familiar with some other OO language and clever enough to recognize patterns, I’d say you’ll probably be fine; take note that I haven’t finished the book, though.
I have to admit that sometimes I get bored with coding. Usually, this means one of two things:
1) I’m too stressed or burned out from working on other things, and my motivation for doing ANYTHING is next to nonexistent, let alone my motivation to work on complex intellectual activities like coding; or
2) I’ve been working on something that’s either too easy or too difficult, and I’m getting bored or frustrated, respectively.
I was getting pretty bored of working with the Python book. I found myself skimming stuff, wishing Shaw would just get to the point already… I think I’m finding that the point where you can just look at code and immediately see what it does means you have to move on, because you’re sitting in a kiddie sandbox. My 12-year-old brother will really find the book interesting, especially the simple game engine near the end, which was supposed to be one of the major final projects–but since I spent a lot of time when I was 12 fiddling around with RPG Maker XP*, my thoughts were more along the lines of, “Cute. Let’s move on.”
And it was time to move on. There’s a lot of stuff in this new book that I don’t know about, which I probably should know about before trying to get into it… but since it’s the only source where I’m finding any mention of these concepts, I’m just going to glark it from context.
Concepts like what the difference between a class and an interface is, and how the syntax for writing them is different… and then there’s this diagram system they use that I’ve never seen before… what “programming to an implementation” means… How come I’ve taken so many programming classes in OO languages, and they’ve never touched on this stuff?
Does all school work this way? You attend classes that teach you the easy half of what you need to know (or next to none of what you need, if it’s high school) until they’re satisfied enough with you to give you a fancy piece of paper, and then you go home and actually learn all your skills yourself? Mostly I’m annoyed on principle, as it’s not so much of a problem in my case–self-paced learning works really well for me–but it doesn’t for everyone, and that is super uncool.
An interesting thing I noticed myself doing while I was going through the Python book: I had read part of the first chapter of the HFDP book, and not really understood it despite trying very hard to do so, so I went back to the Python book. And as I went through it, I kept piecing together how the design pattern worked. So even though what I’d read was mostly Greek to me, having tried to understand it, it stuck in my mind anyway and I was able to use later clues to get it without even looking back at the HFDP book.
Of course, having returned to HFDP, it’s even a little clearer, although I don’t totally get everything the chapter has to say yet. Since this is a complicated book and I need to learn a lot of what’s in it from context (because I’ve never seen a lot of this stuff before and don’t know enough about it to even form questions on it), I’m doing two runs through the book. The first run, I’m just going to read it and try to understand stuff. I’m almost inevitably going to hit a point in the middle of the book where I get stuck and can’t understand anything more, and after that I’m going to skim. But I am going to go through the whole thing because, as mentioned above, stuff I don’t understand apparently sticks anyway if I wrestle with it enough. I didn’t think it would at first because it seems so complicated, but it does and the skill will develop more if I take advantage of it.
Reading HFDP is an experience. In each chapter so far, they present a problem that requires a design solution and they go through several different ways an inexperienced programmer might approach the problem, pointing out the issues and potential issues in each of them. Then they introduce their design pattern, not only coded properly but sometimes it even has extra features; not stuff that bogs down the code, but simply makes it more flexible. Objectively, but especially by comparison to the other code, the final solution is beautiful.
I don’t know if I can explain what constitutes beauty in code to my non-technical readers (if there are any? you guys must have patience). It can be achieving the best, most flexible results by the simplest, most minimal means possible even when the problem is complicated–in fact, that’s probably the most beautiful of code structures, something referred to as “elegance.” To be told your code is elegant is very high praise. Code beauty can also be achieved through ingenuity and creativity in design, although it’s still very important that the code be readable and maintainable, and most of all it should run. There are other ways for code to be beautiful, though, including code that is intentionally designed to do something ridiculous but actually manages to do it, or code that only works because of a loophole in the way the programming language itself is written (there’s a Jargon File example of this too, but I’m not sure where it is).
Head First Design Patterns’ solutions are the first kind of beautiful, which is the kind most worth committing to memory because they’re the most versatile. That’s the selling point of the book, really; that it teaches you good code structure, templates that are reusable, and then it’s your job to decide which one(s) you want and how you want to adjust it to your own needs.
Anyway, as much as I like writing and hopefully also encouraging other book-apprenticed coders and wannabe open-source junkies, I kinda want to go back to my book. I’m leaving this here for the day.
*If you’re not familiar with RPG Maker XP, think of it as kind of like Scratch (or, ostensibly, Alice, which I’ve never used), but more obscure and difficult to use. The map builder for the graphics part of the game is a lot like using virtual Legos. It runs Ruby, but since I didn’t know Ruby, I just used the game’s interface to generate the code line-by-line; its engine for that is closer to the code than the code-generating tools I normally get irritated with (like, you have to manage your variables yourself). I learned some programming logic from it, and a little bit of work with Photoshop for some graphics, but I never became very good at it. Nevertheless, I hammered away at the thing for hours on end, trying to recreate game versions of scenes from the fantasy novels I wrote (I was a weird kid).