Lesson: Show Simplicity, Hide Complexity
I know, I know, I rabbit on about simplicity as though it were the only thing of importance. Because I rabbit on, you’d think that you could look at my codebase and marvel at the tiny number of files and the small number of lines of code. However, if you were to view Charlie’s codebase, you’d see just as many files and lines of code as you’d find in a complex software application. The fact is that any non-trivial software application will require code, and lots of it. Where is the simplicity?
Simplicity comes from avoiding unnecessary complexity, and hiding necessary complexity.
First, simplicity comes from avoiding unnecessary complexity. And what is unnecessary complexity? It is complexity that is there “just in case” you might need it, even if the chance of needing it is about as likely as Kermit the Frog ever realizing the love of Miss Piggy. When I was creating the security infrastructure for Charlie, I had to consider anonymous users. Should I implement the equivalent of ASP.NET 2.0’s Profile object, allowing Charlie to store information about anonymous users, just in case I ever found the need? No. That would be unnecessary complexity. When I was creating the ability for Charlie to host multiple websites from a single installation, I had to consider the possibility of “mini-sites”—a website within a website, like the child portals in DotNetNuke. Should I provide the infrastructure for child websites, just in case I ever found the need? No. That would be unnecessary complexity.
Second, simplicity comes from hiding necessary complexity. And what is necessary complexity? As much as I’d like to come up with an impressive-sounding definition, I think necessary complexity is anything that makes you groan and say, “Fuck, there’s no simpler way to solve this.” While this complexity is necessary, it can still be hidden away in the depths of the application. In my last weblog entry, I described how I was able to add security and globalization to Charlie by tweaking the deep-down Entity System. Here is the bulk of the Article business object before I added security or globalization to Charlie (and using fields rather than properties, just to keep the code sample simple):
public class Article : Entity
{
public String Title;
public String Summary;
public String Content;
}I then added the security infrastructure to Charlie, and here is how the Article business object had to be refined:
public class Article : Entity
{
public String Title;
public String Summary;
public String Content;
}I then added the globalization infrastructure to Charlie, and here is how the Article business object had to be refined:
public class Article : Entity
{
public String Title;
public String Summary;
public String Content;
}Unless my cut-and-paste skills are hobbled, you’ll see that the business object never changed. The hundreds of lines of code needed for security and globalization is necessary complexity, but it is hidden away in the base Entity System.
Sure, this is a simple application of fundamental object-oriented programming, but that is exactly my point. If you take the time to apply simple OOP concepts, the resulting base classes provide fertile soil for your application. From that soil solutions can emerge, which was the topic of the last weblog entry. Into that soil complexity can be buried, which is the topic of this weblog entry.
The lesson is when you discover necessary complexity, see if you can hide that complexity. Bury it in the soil of your application.
by Alister Jones | Next up: When the Student is Ready… →
----
Post a Comment