41. Loose coupling

This post is really for people without formal programming training.

Loose coupling is a programming term, which means making different parts of your code as independent as possible. The opposite is tight coupling, which means your code is woven together so that changes to one part are likely to affect another part. A few examples may help.

Adjusting the drawing origin

I’ll start with something that is important for Codea. Suppose you have a game with lots of objects to draw inside (say) a box, and that you need to move the box and its objects around the screen.

The obvious method is to adjust the x,y values of each of your objects when you draw them. But there is a much easier way.

If you want to draw the box and its objects starting at x,y, then simply use translate(x,y) to move the drawing origin 0,0 to x,y. Then, if you draw anything at 0,0, you will actually draw it at x,y. So now we can draw our box, and all its contents, at 0,0. This means you don’t need to add anything to the x,y coordinates of the box and its objects, and you can always draw them starting at 0,0.

This is loosely coupled, because the box and its objects don’t need to know anything about where they are on the screen, and if later on, you want to change where you put the box, it’s dead easy to do.

The translate function is exactly like real life, when you are drawing on some paper, and pull the paper toward you so you can draw more comfortably instead of having to stretch your arm to draw. Translate just moves the paper up/down and left/right under your pencil.

And the rotate command is similar, turning the paper around under your pencil.

So translate and rotate are extremely useful commands, for keeping your code simpler. I didn’t realise this for quite a while, when I started.

Variables

Another example is variables. A good programmer will tend to use variable names for everything, even constants, because you never know when you might want to change them.

If, for example, you hard code the normal gravity constant (ie as a number) into several places in your code, and then later want to create a moon version, you’ll have to search and replace all the numbers, and you’ll wish you had instead included a line at the beginning saying gravity=xxxxx, which would have made it simple to make the change.

Functions

Beginners often start programming and don’t stop until they’re finished, resulting in a very long pile of unbroken and messy code. It can be very difficult to find errors, and making changes later can be a nightmare, because changing A affects B, and changing C means editing 30 different lines of code, etc.

That’s why most programs have lots of functions, each of which does a little job, and each of which can be carefully tested on its own. This makes it much easier to make changes, and your main program is going to be much cleaner and easier to follow, without all the clutter.

Another way functions can help is to prevent duplicating code. Repeating the same code creates clutter, and can be dangerous if you have to change it later, and if you don’t make the changes exactly the same. Pulling that code into a function removes the duplication completely and is much safer.

Closures, which I have talked about in post 29 and near the end of post 39, are probably the most extreme examples of loose coupling, because they can lock information away so it cannot be accessed by anybody.

Classes

Classes are a good example of loose coupling. Suppose I write some really nice code to save my game progress. Later, I write another game and want to re-use the save game code.

If that code is all tangled up in the rest of the original game code, I am going to have a hard time pulling it out. However, if I had realised at the time that this could be useful later, I could have put all the save game code into its own class, so I can just lift it out and drop it into a new game.

I did this a while back in post 19 when including an undo feature in a board game. That code is in its own class. So is the code I just did in posts 39 and 40, for working with playing cards. Any of them can be copied and pasted straight into other projects.

Breaking your code into completely separate chunks not only makes it more portable, but easier to test, and to maintain, and to extend later.

So classes sound like something really complicated, but they aren’t. Just think of them as a way to break up your code into chunks. And classes also make it easy to create more than one copy of the same thing.

You can also use a table of functions instead of a class. See post 31 for details.

Advertisement