Wrong.net

One of the things that’s been floating around in my mind is the difference between object types and value types.  Conceptually, it’s the difference between a dialog and an integer or string.  In my mind, I understand the intent, but I dislike categorizing by intent, as that leads to fuzzy definitions that eventually become meaningless.

The other way to define value types is by storage - stack vs. heap.  I really don’t like this, though, as one of the advantages of value types is that it’s safe to pass them by reference.  I would say a string in C# is a value type, even though it’s a class (and therefore passed by reference).

So, here’s a set of criteria to determine if something is a value type or not.  These criteria don’t specify whether a particular type could be implemented as a value type, only whether or not they are a value type as implemented.

1. The type must be immutable.  Any methods called on the type cannot change its members.  If a modification is desired, the method should create a new object of the same type, and return that object.
2. The type must only reference other value types.

If your type follows these two rules, it is guaranteed to be side-effect free.

Rule #2 might be relaxed, if the reference type that the type holds is guaranteed to never be exposed (so nothing can ever modify it), and the object never modifies it itself.

And this time I’m going to drift into theory-land for a bit, and I’m not particularly fond of theory-land.  I prefer "getting-stuff-done-land," which is quite often located on another continent.

Conceptually, objects are these things that sit in space and receive and spit out messages.  And if we look at our User class in that way, it kind of makes sense.  We define the behavior of the User object as receiving a message to set its name, and when it does so, it should then emit a message that it should be saved.

And this is a pretty convenient way to think of objects.  It also isn’t modeled well by most object-oriented languages.

C++-derived languages handle relationships of "is-a" and "has-a" types very well.  But, what we really want here is a "talks-to-a" relationship.  There’s no real first-class way to do that.

Also, they handle incoming messages very well, by means of the public interface of an object.  But, outgoing messages are a little tougher.  Sure, you can do all sorts of things with message receivers and emitters, but realistically, people are going to use the built-in constructs of the language.  So, if we want to model objects as message receivers (easy) and emitters (not easy), we should do it in as basic a way as possible.

And now we get back to "getting-stuff-done-land."  Looking at our User class from the past two entries, we can look at the interface we define as the outgoing messages that the object can emit.  Viewed in that way, it makes sense that the object would own that interface - who else would?  And why would an outgoing message from a user know anything about a database?

There’s other ways to model an outgoing message, and they all pretty much boil down to function pointers.

First, you can use virtual protected methods to define messages, and then override them in derived classes to translate them to the incoming messages that are desired by another component/object.  This method has the advantages of looking more traditional, but the disadvantage of not being able to mix-and-match receivers at runtime.

Secondly, you can use events and delegates.  Combined with lambda expressions in C# 3, this can be an effective way to define outgoing messages.  It has the advantage of not requiring additional classes, but the disadvantage is that you have to hook up each event individually.  Also, events can provide multiple dispatch, but that can become wonky if you want to remove individual anonymous delegates, so I’m counting that as a neutral.

So, reading the last post, it might seem like I’m advocating a lot of extra work to do anything.  Having each class create its own interfaces for everything probably seems a bit insane.  Wouldn’t it be better to define a single, universal interface for, say, a database?

Short answer:  no.  By doing so, you’ll inevitably end up intermingling aspects of the dependency with your core code.  In the User example in the previous post, even if you abstract the DBConnection to an IDatabase, you still have to deal with the fact that you’re now tied to a database, and have intermingled knowledge of the database layout and SQL variant you’re using into your User class.

The problem is that each class has its “natural” language.  The “natural” language of the User class is “save the user with this id and this name” (and whatever other information is appropriate).  The natural language of the database is “run this sql command.”

Just as it would be inappropriate to put code specific to the User object in the database, it’s also inappropriate to put database specific code in the user.

So, instead, what we can do is create small classes that take the output of one class (the User, in this case), and turn it into the input expected by the other class (the database, file system, etc.).  There’s no real extra code required to do this, as all of the code would have to be written ayway.  By doing this, you remove the knowledge of this glue code out of either of the two classes, and allow it to live in its own classes, possibly even its own assemblies.

There are times, though, that you do want to maintain a common interface between classes.  But only do this if the classes in question naturally end up with the same interface, or it’s a “natural” dependency - if you’re writing something that retrieves data and writes to a disk, then a mocked file system is appropriate.  An FTP client would be a good example of this, as there wouldn’t really be a point to writing an FTP client that saved to a database.

Additionally, if the “glue” classes are more than simple pass-through classes, it may be worthwhile to test them more thoroughly, and so mocking their underlying data store may be appropriate.

There’s two things you frequently hear when talking to developers about TDD.  It’s either "our code is too complicated, you can’t separate it" or "how can you test a database" (or graphics system, or insert other complicated system).

Here’s an example of code that someone might have in mind.

public class User
{
    private DBConnection connection;
    public string Name
    {
        set { SetName(value); }
    }

    private void SetName(string name)
    {
        this.name = name;
        // other stuff…

        connection.ExecuteSQL("update users set name = ‘" + name + "’ where id = " + id);
    }
}

So, usually someone will want to create a mock object for the database for testing purposes.  That’s one way to do it.  But, I’m not sure it’s the best way.  After all, you want to test your class, not your understanding of the database!

There’s another issue here.  The User class knows waaaaay too much about the database for its own good.  I mean, what if we wanted to save to a file system?  We can’t, at least without serious rework.  While we could replace the database connection with a different type, we’re still tightly coupling to the idea of a database.

What we really want to do is save the user info.  So let’s just make a method that does that.

private void SetName(string name)
{
    this.name = name;
    // other stuff…
    SaveUser();
}

private void SaveUser()
{
    connection.ExecuteSQL("update users set name = ‘" + name + "’ where id = " + id);
}

Okay, that’s a little better.  Now we’ve removed the implementation details of saving the user from the SetName method.  It now pretty much says what, conceptually, we want to do.  All the database stuff is in its own method.

But, being in its own method doesn’t really allow us to change anything.  So, let’s extract an interface.

public interface IUserPersistence
{
    void SaveUser(int id, string name);
}

IUserPersistence persistence;

private void SetName(string name)
{
    this.name = name;
    // other stuff…
    persistence.SaveUser(id, name);
}

And now, our user class doesn’t even have to know about a database at all, or maintain a reference to its connection.  Instead of giving it a DBConnection, we just give it a IUserPersistence object.  We can then test away to our heart’s content, throw whatever exceptions we want, without having to worry about trying to mock anything as heavyweight as a whole database.  We also remove all database specific code from our user class, allowing it to be reused elsewhere.

It’s also conceptually cleaner - the user class now only has to know about the idea of saving itself, not the specific details.

The drawback of this is that it does potentially pollute the API space a bit.  One way to get around this is to set the instance of the interface to protected, and not expose them on the default object.  Then, you can write a test object which inherits from the normal class which exposes a setter.

So, the answer to "how do I mock a database" is simple - you don’t.

“Plans are nothing.  Planning is everything.” - Dwight D. Eisenhower

One of the common criticisms I see of any kind of agile development (note: agile with a little a, not a capital A) is that people seem to believe that agile development means that you don’t plan, don’t design, and don’t document.

In my opinion, this couldn’t be further from the truth.

In fact, I’d go so far as to say that agile development involves more planning, more design, and more useful documentation than other methodologies.  The key difference is when you do the planning, to what extent, and what information you derive from it.

I’ve worked on projects that planned to the extreme.  There was a gantt chart which specified what you would be doing at 2pm on Thursday.  Now, that’s somewhat okay, except that the Thursday in question was two years into the future.

Let’s come up with a hypothetical example.  Let’s say you’re going to start a brand new Generic Fantasy MMO from scratch.  Do you just start diving in and writing code and making art?  I’d hope not, and I doubt anybody with a brain would suggest that.

You start with planning.  You know you’re going to need art, some levels, some amount of design documentation, and code.

You’ll know you’ll need some areas for people to walk around and swing their swords.  How many?  Well, that’s a function of how large they are, but we’ll say 100 distinct “areas,” where each area is more-or-less self contained.  How will we make them?  In Max or Maya?  A custom tool?  Who will make them?  If designers are doing the layout flow, we probably don’t want to have them use Max, so we’ll need a custom tool.  How will that tool work?  Will it plug together pieces Lego-style?  While it give more freedom, and then allow artists to perform a beautification pass?  How many levels will be inside vs. outside, and how does that impact what tools are needed?  What are the plans for future expansion after release?

Once we have some of these answers, we can start putting together a plan.  Let’s say we want a 50/50 mix of outdoors and indoor areas, so we’ll need relatively strong tools for both.  We want designers to do at least initial layout, and we’re pretty sure we can use a “Lego-brick” approach.  We’ll still need artists to create the bricks.  But, we can start using this knowledge to make a plan for what resource we’ll need, when we’ll need them, and how we can go about putting this thing together.  In this case, we’ll probably need at least one programmer pretty quick, with at least some art time not too long after that to create some sample “bricks” (once we get past the programmer art stage).  We can make a rough guess as to when at least some functionality will be done, and start making sure we have more level designers and artists for when that happens.

And the plan will be wrong.  Period, end of story, no matter what.  Your estimates will be off.  Things will change, your knowledge of the problem will increase, and you will have to adapt.

So, in that case, what’s the point of planning?  In this case, the simple act of planning gave us a good amount of the information that we needed at that moment to make the decisions we needed to, and could make, right then.  It gave us enough information to start making staffing decisions, and helped us define the scope of what we were doing.  It made sure that we thought the problem of “how do we make levels” through, and didn’t miss any major pieces of that particular puzzle.

We didn’t try to nail down too many specific details.  We didn’t say exactly what each dungeon should be, or how we were connecting areas, or anything at all of that nature.  Those are details that are unimportant at this time.  They don’t impact a single thing that we’d do for the next month or so.  So, instead of wasting time arguing about them now, do another planning session in a month (or 2-3 weeks, or whenever), revise the plan as your knowledge has increased, and work from there.

People using agile development (I refuse to use “agile” as a noun or to capitalize it) do plan.  They plan a lot.  They just see the value of planning in the information that comes out of the exercise, not the specific set of dates and requirements.

This seems directly counter to what I’ve seen in BDUF-type organizations.  Plans, in those orgs, tend to focus excessively on the detail level, and actually focus less on the high-level decisions.  In my experience, those are the wrong things to worry about at the beginning of any project.  They’re almost always easy to change, require knowledge you don’t have anyway, and subject to iteration.  Yet, somehow, I see planning documents that focus extensively on these minor details, and merely imply the larger decisions via these details.

Everyone’s had to deal with it.  The big, nasty project, where everything links to everything, and anything you do can have seemingly random effects in apparently unrelated areas.

So, let’s look at some ways to avoid that.

But first, let’s define what we mean by “coupled.”  Two pieces of code (classes, modules, whatever) are coupled if they have to know how each other work in order to function.  Couplings can exist one-way, or two-way.  Some coupling is good - programs probably wouldn’t do much without them.

Where the sinister evil starts to sneak in is unnecessary coupling, and unnecessary intimacy.

To start with, let’s look at a piece of code:

public class SomeClass
{
    public void DoSomethingToCharacter(Character c)
    {
        string username = c.Connection.User.Name;
    }
}

Okay, so it doesn’t do much at this point.  But it’s a pretty good start as to where there might be a problem.

And what problem is that?

Well, it’s pretty apparent that this method needs to do something with the character’s name.  But to get that information, we have to go through both the connection and user properties.

This opens us up to problems.  First, it means we have a physical dependency on those classes, which can create compilation time issues.

Secondly, it means that to get the data we want, we have to know quite a bit about the class we’re using.  We have to know that it has a connection object, and that that object has a user object, and that object has a name.  I don’t want to know that much.  I just want the user name from the character!

The worst problem is that we open ourselves up to build breaks every time we use this access pattern.  If any of those classes change, we break.  And probably in lots and lots of places.

Let’s look at an alternate:

public class SomeClass
{
    public void DoSomethingToCharacter(Character c)
    {
        string username = c.UserName;
    }
}

Ah, yes.  Isn’t that pretty?  Now our code only cares about the character we class.  We don’t know how many layers of ugliness are going on underneath, and we don’t need to.  Even better, if one of them breaks, the damage is going to be limited to inside the character class itself - which means an obvious place to fix, instead of hunting down those chains of objects all over your codebase.

Oh, and for what it’s worth - those chains of objects have a name.  They’re called “train wrecks,” after all of those objects smashed into each other.  It’s not a term of endearment.

And what I’ve been describing has a name as well - it’s called the Law of Demeter.  It basically states that a given method can only use methods internal to objects it owns, on objects that are passed in, or on objects it directly creates.

No, really.

The usual analogy that we here is that software development is like building bridges.  This makes for a nice picture, with lots of little programmers carrying around bricks made of ones and zeroes.

But, it doesn’t seem to fit reality very often.  And attempts to build software in that way tend to have certain, repeated issues.

So, maybe, programmers are more like artists?  Sounds good.  But, what does an artist do?  How do they sit down and create a masterpiece painting?

The first thing that an artist will do is do some sketches - studies of individual parts of the final painting, some sketches giving the overall composition.  At this point, they’re trying out techniques, working through tricky areas, and deciding how they want the painting as a whole to look.

Some of these sketches may end up relatively detailed, but they’re all ultimately designed for one purpose:  To be discarded and thrown away.  None will be the ultimate painting.  They’re nothing more than preparation.

So then, the artist will begin by stretching his canvas, putting on a layer of primer/gesso (or not), and then generally doing a sketch right on the canvas.  This sketch is extremely rough, and is only meant to show the general size, shape, proportion and position of the final visual elements.  As the artist puts down these lines, he puts them down very lightly, until he has more confidence in the final placement.

Next comes the underpainting.  The painter will then work with (generally) a single color of paint at various dilution levels, to block in the large areas of light and shadow for the painting.  The painting will still have a loose, unfinished look about it, but the major forms will start to be visible.

As the painter continues, they will add in other colors, begin to add large details, and refine the painting.  Normally, they will work more or less uniformly over most of the painting - they won’t heavily favor one area over another, unless doing so is part of the composition.

To me, this is much more a description of the software development process than any engineering analogy.  When we write software, we first might make prototypes to test out individual concepts or systems, knowing full well that most of them will be thrown away.

When we start the program for real, it is generally best to start with only bare functionality in the basic systems of the application.  Not doing too much too fast leaves us in a better position to change our minds if we find we made a mistake.

As the application grows, we start more rigidly defining the areas, always taking care to look at the whole of the application instead of just the one part we’re working one at the moment.

Just wiped out every trace of the old site.  I didn’t like some of the writing, and wanted to start fresh.

With the wipe comes a commitment to post at least weekly, and to try to use a more structured writing style.  More to come…