Working Around the Decorator Pattern

…Which still seems kind of ugly to me. Less so than before now that I’ve thought about it. But I’ve also had the problem of making a better design in my mental background space for a few days. I’m not entirely sure precisely what my growing sense of program design takes offense to about the pattern–although I have a general idea and a few guesses–or where it’s going with how to fix the issue.

Note: If you’re not familiar with program patterns, this will probably be an incomprehensible blog post. My own understanding of this topic is almost nonexistent, so I can’t explain what I’m talking about, and you wouldn’t want to learn from me anyway. I’m writing mainly for my own mental clarity, and to flesh out the ideas that have been nagging me.

The only hint of a solution I’ve posed on here is that I would use more of a Strategy-shaped pattern.

Issues with Decorator that I can point out: It’s big and clunky. You can’t see everything that’s going on with your objects, and you can’t rely on being able to test for all their characteristics if you need to–which means that if a future feature needed to go back and see that information, you’d have to restructure the whole program or implement a klugey hack that would be even messier. So it’s brittle.

Probably for simple stuff it’s fine, and even in special “big” cases, but… I had a similar reaction to reading about it as when my Intro to Programming Logic class taught us about bubble sort algorithms. Roughly: “Ick.”

In the book’s example, you’re using decorators to customize coffee orders with different toppings: mocha, whipped cream, soy, steamed milk, whatever. I’ve been thinking about how you could use implementations in this scenario, or maybe put in special dedicated methods to add toppings.

Personally, I would use arrays for–

Aw, man… am I venturing into LISP territory, using arrays for stuff that probably doesn’t need arrays?

Whatever.

My first impulse is to give each individual drink object a toppingList array to work with (perhaps inherited from a superclass), and let it call different methods which would append toppings to toppingList, which could be evaluated later–for the purposes of charging extra for each topping and so on.

But I don’t like that idea much either.

Using arrays is a good start, but there has to be a way to use an interface or an abstract superclass to standardize things.

All the drinks have toppings (or lack thereof). Even if there’s another drink which would be awful combined with certain toppings, it won’t hurt to have the potential for toppings in general to exist, even if there aren’t any appealing ones right now.

Like I said, Strategy pattern would be a good one to take a hint from. You could implement an interface for toppings, and then methods for each topping that add the topping to the drink’s toppingList array. If you need to, you can probably increment price at this time too.

The problem would be if permissions didn’t let you edit the drink’s variables (toppingList, drinkPrice, etc)? I don’t think that’s an issue, but I haven’t seen the code. Flowcharts like this book is littered with are really helpful to understand the design patterns, but they just don’t give you (me, anyway) the whole picture.

But if you did implement new toppings, you would have to go back and add support for them wherever the toppingList array is evaluated (near the end of the program, I think), which is something you’re supposed to avoid. Maybe you could hack around that, though. It would still leave your objects in a more usable state regarding how much information you can access from them.

Again, I’m still on my first, light run-through of this book, so there’s a lot I don’t know. If you’re not already familiar with design patterns and what is good practice, don’t let my speculative discussion teach you bad practice.

A few more projects

I’ve started teaching Python to my 12yo. brother Ben. He picks it up really quickly and asks the right questions; his problem is that he doesn’t make the mistakes that the Python book keeps trying to get him to make, the ones he’s supposed to learn from. He’s already meticulous, so if I don’t intervene and point out all the ways you can screw up a program, he won’t have the experience of knowing what it looks like when you do make stupid mistakes. Because everyone makes stupid mistakes in programming. It’s just a thing that’s going to happen, no matter what.

So far, the design patterns book I’ve been reading has covered the Strategy pattern, the Observer pattern, and the Decorator pattern. I like Strategy and Observer, but I don’t like Decorator. I keep getting this feeling like… I would do it differently, use more of a Strategy-shaped design. The book keeps talking about a “Factory” pattern; maybe that’s what I’m thinking of but can’t pin down. I just don’t like Decorator on its own. It seems kind of unnecessarily complex… obtuse… clunky. Maybe I’ll like it when combined with Factory, or maybe I don’t understand it well enough to get why you’d want to do things that way.

Meanwhile, the book is teaching me more about OO principles than any programming book I’ve ever seen. Between Head First Design Patterns and Google, I’m seeing a lot more of what you can do with objects via example than is ever really explained in other contexts. School teaches you to type

public static void main (String[] args) {  }

(or equivalent for non-Java languages) but never actually shows you a program where you use publicly-accessible methods from another class; I’m still not really sure what static does. They teach you what classes and objects are–sort of–but don’t teach you how they can really be used. They don’t teach you what an interface is, or how libraries actually work. They teach you syntax and how to solve toy problems. I have a feeling I’m going to end up teaching some other new programming grad I’ll have to work with about everything the classes missed. In fact, if I can find the patience to type these things up, maybe I should post them here.

I can see my own progress by the fact that the source code for Tetravex, which I downloaded on my Debian VM, is now magically understandable. Not sure how that happened, but there are a few bugs I want to send in a patch for–if they haven’t already been fixed. If I do that, it’ll be my first contribution to open-source. 🙂

Design Patterns

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).

A Full Summer

I have identified the biggest gap in my knowledge and have been working on patching it. Took me long enough.

The major problem is that schools just don’t teach object-oriented programming. Sure, they teach languages that use it… they show you how to program dinky little projects in them, make Hangman games and so on. But they don’t teach OOP principles, and that’s a wall I’ve run into. It’s why I’ve never felt comfortable saying I have a working knowledge of a language.

So I went back to Learn Python the Hard Way. I got bored with this book earlier because I was determined not to skip stuff in case I missed something important (a good tactic dealing with textbooks that aren’t written so well, which is most textbooks), but the book was written with the idea that it’d be your first programming language, and it wasn’t mine. It’s also a little condescending, but this is probably justified considering the book’s target audience… you HAVE to talk down to people a little if they’re not sufficiently tech already.

Determined to learn OOP principles, I recently dived back into the book. I spent a while grinding through the first 20 or so exercises, skipping most of the study drills because I could answer the questions they posed without looking up the information, and making one or two snarky notes in the margins for the benefit of my younger brother who’ll be inheriting the book once I’m finished with it. I had a trip out of town with my parents recently and took the book along, reading it in the car and suchlike.

After reading ahead quite a bit, I decided not to bother with anything else until exercise 40, when the book starts in on OOP principles. Yes, that’s skipping a quarter of the book. No, it probably won’t help me learn Python’s syntax. But let’s face it, Python’s syntax is designed to be non-headachey and easy to pick up anyway, and it’s not what I came for.

 

Exactly a month from today is my 18th birthday. This opens up a lot to me which will keep me busy.

First, I’ll be working on getting a driver’s license. Yes, I’m in America and if I’d been more on-the-ball about things I could have gotten it before now, but I waited too long to get my learner’s permit and there are weird legal qualifications about how long you’ve had the permit before you can try for a driver’s license if you’re underage.

Second, I can apply for more jobs. It’s ridiculously difficult to get a job in my city if you’re under 18. There are only a few places that’ll even look at your application. Since I’m going to be moving out next year, and I don’t particularly want to accumulate massive amounts of debt, I need several thousand dollars in order to move into and outfit my teeny-weeny apartment (which is both cheaper and saner than living in the dorms at most colleges). This requires some planning, and, yes, a job.

I have a few places I’d really, really like to work. Particularly, I want to see if I can land a job working at this car dealership that needs techs–I haven’t seen much information on the job, but my best guess is that they need someone to service the computers embedded into their luxury cars. Maybe those computers even run Linux. That would be such a cool job–something I’d really want on my resume–and this is one job where I’d probably get to see better than minimum wage. Even if my guess about what the job does is off, finding a tech-related position would be a real boon.

 

Third, I’ll also be finding out what community college I’ll be attending next year. The one I’m attending now is mostly fine and I like a lot of the people there, but I have… a few HR issues with one of their most heavily employed teachers. Let’s just say that if you’re a teenage girl in a programming major, not everybody respects you; the teachers are not exempt from this effect, and not all of them are able to keep their personal resignations on this front to themselves. The way the school dealt with the issue left something to be desired. I won’t name names, or even reveal the teacher’s gender.

This is not an issue of disliking this person. This is an issue of, “this person does not respect me whatsoever and actively tries to create a toxic environment for me.” They teach many of the classes I need for the rest of my degree.

So I’ve been looking into finishing my AAS somewhere else. The idea of not paying this person’s salary is very appealing. However, if I end up taking their classes again, I’ll start recording the classes on the premise of wanting to listen to the lectures later. If said teacher intends to continue their disdainful attitude, I’ll have some more evidential weight on my side and won’t so easily be dismissed. Such a recording device would most likely prevent this behavior entirely, though; the teacher is too smart to allow me such evidence. If the teacher refuses to allow me to record his lectures, I’ll ask them to explain why, which will be a difficult question, especially since they make lots of videos and put them on the Internet.

Fortunately, it may not come up. There is another community college nearby with a very similar track to what I’ve already done; most of my courses will probably map.

 

Because I’ll be so busy, I’m hoping I can tackle learning OOP and get that particular project finished within the next month.

Better get on that.