CSS styling and object orientated design

Last week’s programming surgery was the most popular yet, with 5 attendees, and a diverse set of programming topics to discuss. I won’t attempt a detailed record of the conversations as my notes were too brief for that, but I will summarize a couple of interesting topics.

The first was styling with CSS. Somewhat fortuitously I had just been working on some HTML on another project and so I had some of the rules freshly revised. My go to resource for this kind of thing is W3Schools. They explain how to use HTML and CSS together and provide a live editor for trying out examples. This was particularly useful when working out the element selection feature.

For example, to style a link only when it is the child of a <div> tag:

<div>
    <a href="http://w3schools.com/">Example link</a>
</div>

You can use this CSS code:

div > a {
    background-color: yellow;
}

The > symbol says that this rule applies only to the tag on the right when it is nested inside the tag on the left.

Another good resource for both learning and tinkering with HTML is Trinket. We use Trinket a lot with the code club because it allows you build examples using multiple files and share them.

My limited experience with HTML and CSS might get me through simple composing and styling issues. But for more professional help or advice in Croydon, I recommend contacting Sleeptwitch.

The second topic I found interesting was a more general request for help on breaking up a growing body of purely procedural code into separate classes and objects. An idea I like to keep in mind when performing this kind of operation is Tell Don’t Ask; which is an informal version of the Law of Demeter. In a nutshell, the idea is to ask the objects in your program to perform tasks for you rather than micro-managing them yourself.

Here is a quick RPG style video game example. Imagine we have an object Player that we want to damage another object Monster. A purely procedural approach might be to access the internals of both classes:

monster.hitPoints -= player.attackDamage;

The Tell Don’t Ask approach might instead instruct the Player object to do the work:

player.damage(monster);

Internally, the player would then forward the instruction to the monster:

void Player::damage(Creature target)
{
    target.takeDamage(attackDamage);
}

And the monster would need to respond to that:

void Monster::takeDamage(int damage)
{
    hitPoints -= damage;
}

Initially it seems overly complicated in examples like this, but the advantages soon begin to outweigh the disadvantages as your project scales up in size. There is also a disadvantage in that your game’s data begins to get fragmented. In simulations with large numbers of objects this can lead into performance issues, but that’s a topic for another time.

Some good resources for turning procedural code into object oriented code are Refactoring by Martin Fowler and Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, also known as the Gang of Four.