private override

Audience… #2

I started to write this bit on my previous post, but nixed it because I thought maybe it was just something that was going on in my head, but lo and behold, it at least happens to Jeremy Miller as well.

Before I get started, let me state that I do not claim to know everything about programming or even lots of things, and I am certainly not the best developer (no, I'm not saying I'm bad either!).  However I am willing to learn and am learning (LOTS), and thats all I can ask anyone else to do too.  Thats the only way we can progress to where we need to be.

The target I'm going for here is the code itself.

I write and design code at the highest level of technical ability that I can.  That means if a particular pattern makes sense, I'll use it.  If I can inject the dependencies in some way or another to make it testable, I'll do it.  I (try to) write my code as if I'm the audience.

Many people (I am guilty of this too), all too often try to write code that prevents the consumers of it from screwing stuff up.  I normally think this is just programmer paranoia, but I think it is a reasonable consideration.

I hate having to cater to the LCD in my code, but if I KNOW that Barney Fife's grandson, the programmer, (and he is not in my company) is going to be a consumer of my code, then I may 'dumb it down' so he doesn't end up screwing something up.  If he is part of my company, I'll take some responsibility and help him get to where he needs to be so he can better understand the concepts.

Its a careful consideration that, like the UI and usability experts of the world, we don't always get right.  What audience do you cater to when writing your code?

Equality Assertions

I ran across a testing situation the other day when I needed to compare several properties on two objects, and assert that they were all equal.  In my next test, I wanted to assert that those same properties were all not equal.  I hate copying and pasting a list of properties to assert against, and just changing the method call from Assert.AreEqual to Assert.AreNotEqual.

The solution many might suggest is implementing the Equals method of my class.  However, this would be injecting code into my domain class that doesn't belong there since it doesn't get used in the application domain, only in the test domain, or it may already be implemented for its real domain use.  I don't see this as a viable solution.

My solution.  Since Assert.AreEqual and Assert.AreNotEqual have the same signature, we can create a delegate and pass the correct assertion method to a new method which we might call AssertProperties.  It might look something like the following:

[Test]
public void PropsAreEqual()
{
	Coder c1 = new Coder("jon", "fuller", "ruby");
	Coder c2 = new Coder("jon", "fuller", "c#");

	AssertProperties(c1, c2, new DAssertEquality(Assert.AreEqual));
}

[Test]
public void PropsAreNotEqual()
{
	Coder c1 = new Coder("jon" , "fuller"   , "ruby");
	Coder c2 = new Coder("mark", "garringer", "c#");

	AssertProperties(c1, c2, new DAssertEquality(Assert.AreNotEqual));
}

private void AssertProperties(Coder expected, Coder actual, DAssertEquality asserter)
{
	asserter(expected.FirstName, actual.FirstName);
	asserter(expected.LastName , actual.LastName );
}

Thanks Mark for lending me your name.  Anyone have a better solution?  Feel free to show me up!