Lesson: Don’t Forget .NET
In an earlier weblog entry, I noted that I get frustrated by writers who discuss only the “how” of software programming, without discussing the associated “why” of software development. To redress this—if only in the little world of Charlie—I am trying to discuss why I have made certain design decisions, and the consequences and limitations of those decisions. Am I doing any better than the writers I have implicity criticised? I have no idea, since only one person responded to my request for feedback (God bless you, Garbin). Even so, I’ll persist with my efforts to talk about development from a slightly different perspective.
Well, another thing that frustrates me in reading about software development is the common feeling that, “Boy, I must be dumb.” I may read an article where a developer provides a little component, and then describes that component. If the article is written by a first-rate developer, the code looks so clean and so effective that I end up feeling a bit depressed—feeling sure that I’m simply not smart enough to ever write such good code.
The thought that gets me beyond such self-doubt is the image of a graceful duck. To a person standing on the shore of a pond, the duck appears to glide gracefully and effortlessly across the surface of the pond. What the observer does not see is that, below the surface, the duck is paddling like mad. It helps me to think that below the surface of code presented by a first-rate developer, the developer had to paddle like mad to arrive at that final code.
While I am not a first-rate developer, I’d still like to share some of the mad paddling that has gone into the development of Charlie. Specifically, I’d like to share some of the mistakes I made, and the lessons learned from those mistakes.
In developing Charlie’s architecture, I did a smart thing and included in the diagram a Foundation layer, which would comprise the .NET Framework Class Library. That smart step was, sure enough, followed by the dumb step of completely forgetting that foundation.
In coming up with the implementation of the Presenter object, I had to decide what types would be used to represent the Model, the View, and the Controller objects that the Presenter brings together. The View was easy, as I had created a new base View class that inherits from ASP.NET’s UserControl class. The Controller was easy too, because I just created a new base Controller class. But the Model had me stumped. Sometimes the Model would be a single Entity, and other times it would be an EntityCollection (refer to the Entity System). The problem to be solved was what type could the Presenter use to represent the Model? To illustrate, here is the relevant code from the Presenter class:
public abstract class Presenter
{
public abstract ????? LoadModel(Int32 id);
public abstract View GetView(ViewMode viewMode);
public abstract Controller GetController(ViewMode viewMode);
}A concrete Presenter can easily implement the GetView method, since I had come up with a base View class. The concrete Presenter can easily implement the GetController method, since I had come up with a base Controller class. But the LoadModel method was different, because there was no base Model class. Rather, sometimes the Model would be an Entity, and sometimes the Model would be an EntityCollection, and sometimes the model might be something else. I put the two entity classes side by side in Visual Studio, and looked that their respective declarations:
public abstract class Entity
{
}
public abstract class EntityCollection : CollectionBase
{
}The Entity class had no base class; it is a brand new class. The EntityCollection, on the other hand, derives from the existing CollectionBase class. What do these two classes share in common, such that the Presenter has a known type to work with? This had me scratching my head and ultimately putting pencil to paper. I thought about introducing a new Model class that contained one Entity and one EntityCollection, and the consuming Presenter would have to test which item was not null. I then thought about introducing an IModel interface, and force both the Entity and the EntityCollection classes to implement that interface. I then come up with other ideas too, but got so confused that I ended up taking a long ride on my motorbike:
The answer to this problem is embarrassingly obvious. However, I was so focused on Charlie that I had completely forgotten the reality that I was developing against the .NET Framework Class Library. While I was out riding the obvious answer became, well, obvious. I had clear forgotten that every single object in a .NET application derives from the base System.Object class. While it appeared that the Entity class and the EntityCollection class shared nothing in common, that was untrue. Both derive from the base Object class.
public abstract class Presenter
{
public abstract Object LoadModel(Int32 id);
public abstract View GetView(ViewMode viewMode);
public abstract Controller GetController(ViewMode viewMode);
}Having written the above description, I am very tempted not to publish this weblog entry. The fact that I had forgotten the base System.Object class is truly embarrassing. Who would ever trust a .NET developer that forgets this fundamental class? So, while I am deeply embarrassed by this gaffe, I did promise that this blog would be a true account of “the trials and errors of a self-taught developer creating his first web application.” So there you have it: the dumbest mistake I have made so far, and an example of this duck paddling madly beneath the surface.
by Alister Jones | Next up: A Dummy’s Approach to Agile Development →
----
Post a Comment