Archive for October, 2008
Write Big to Write Small
Writing code is like writing literature. Sometimes you have to write big to write small.
OK, if you’re a rock star, you might be able to think big and write small, but I can’t manage that feat. I often need a day of hunting down nasty copy-and-paste bugs before I realize, hey, all this stuff is redundant. I can write a function that makes this duplication unnecessary.
I can’t count the number of times I’ve tried to write concise, elegant code from the start, only to find that I’ve been writing small by thinking small. Getting lost in the details is a great way to write optimized code that works like a charm — but doesn’t actually do anything of value.
Once I thought that design patterns might be the answer to my programming struggles. Then I discovered that my accuracy rate in picking the right pattern for any given programming problem was really poor. More often, it’s led me to implement overly complex solutions for simple problems.
For a long time, I thought it might be my lack of a computer science degree. But I haven’t found a programming style or development framework that fixes the problem. Maybe there just isn’t an efficient way for me to get my thoughts into the computer. The only way I know to do it is to write a big, sloppy mess at the start. Then I’ll slowly, carefully, edit it down to its bare essentials.
Mozart might be able to write a symphony in a single sitting without penning a stray note. Not me.
Switch By Type in C#
The introduction of generics into C# 2.0 simplified many programming tasks. It especially helped in the creation of type-safe collections.
During our reworking of the Infovark data access layer, we created several generic methods to return items from our database. This allowed us to eliminate many duplicated methods and eliminate a lot of type casting. For example, before we began using generics, we had methods with signatures like this:
-
public Entity GetEntity(long id, int revision) { … }
-
public Relationship GetRelationship(long id, int revision) { … }
-
public Resource GetResource(long id, int revision) { … }
became this after our refactoring:
-
public T GetObject<T>(long id, int revision) where T : MetaInstance
-
{
-
Type type = typeof(T);
-
-
if (type == typeof(Entity)) return _DatabaseHandler.GetEntity(id, revision) as T;
-
if (type == typeof(Relationship)) return _DatabaseHandler.GetRelationship(id, revision) as T;
-
if (type == typeof(Resource)) return _DatabaseHandler.GetResource(id, revision) as T;
-
-
return null;
-
}
Wait a minute. All we’re doing here is wrapping all our unique methods up in a generic method! Why bother? Good question. We abandoned that approach in favor of something more sensible later on.
That’s actually not the point of this post. The point is that C# doesn’t have the ability to perform a switch on types. See all those if statements in our generic method? That’s how we worked around the lack of type switching. If anyone has a better approach, we’d like to hear it.
Peter Hallam’s WebLog provides more information about why C# doesn’t have the ability to switch on a type. I’m not convinced by the reasons outlined there. As one commenter noted, there’s already a type-switching construct in C#: the catch statement.
UPDATE: Switching by type is a common problem with MVC frameworks. There’s been quite a lot of discussion on Stack Overflow with regard to the best way to deal with this issue.
- C# Switch Limitations
- Is there a better alternative to switch on type?
- MVC specific: Selecting the correct view for an object type
One-Way Serialization
Has anyone found a good pattern for serialization without deserialization?
In my previous post about mixing serialization, I mentioned that we’d implemented the IXmlSerializable interface in many of our classes. The main reason for doing this was to include elements and attributes that were read-only.
In other words, we wanted additional information to appear in the serialized stream. This additional information is not needed in order to rehydrate the object.
Why would you want to do that?
Most serialization frameworks don’t handle this case. After all, if the point of serialization is to transport an object across the wire, cluttering up the stream with extra information is wasteful. Besides, you can’t dictate what someone on the other side might do with the data. Nicholas Allen discusses this point in his post explaining why read-only data members are not supported in WCF.
While I understand his point from an object remoting perspective, the reason for choosing XML as a data format in the first place was to allow for human readability. What if you want to embed metadata in your XML that doesn’t affect the behavior of the object? You’d need to include it in the XML output, but you aren’t interested reading it back in from an XML stream. What’s the best way to achieve this?
For example, in our data layer we have a Version object that brings together information about when the object was created and by whom, when it was modified and by whom, as well as the object’s revision number. It’s useful to have this information in resulting XML string, but we don’t need to read it back in.
So here’s my question: Are we doing this wrong? Does the need for one-way serialization indicate a problem with our object model? Is it a code smell, or is it simply an edge case not considered by existing frameworks?
