Archive for the ‘Design Patterns’ Category

Separation of Concerns – A real world lesson

July 13, 2012 Leave a comment

About a year ago I was tasked with creating a simple module for my company that could manage notes for the various system “entities” — things like invoices and customers that might benefit by having explanations or instructions. In essence a user could select one of these objects and choose to view or edit any existing notes in a container/widget format (a repeater with user controls for each note) with the ability to create new notes as well. The intention was to provide instant information and feedback across all our various applications and web sites for all permitted users to consume, including our employees as well as clients. This module was completed and implemented and has greatly improved communication and visibility in key areas of our operations.

Very recently another project has arisen that involved messages. Our company has found itself in the position of needing a task-based messaging system that would be used internally as a sort of workflow communication system between departments. In a nutshell it would allow a task with instructional message and association to a system entity (again, an invoice or customer) to be assigned to a person and then sent out for that person to take action upon and, when completed, close the task. At the UI level there would be host client applications that would expose some widget or “message center” where the user could be alerted to open tasks and within a single click quickly be navigated to the right place to perform the necessary actions. Of course this would involve a queue, periodic pop-up alerts and a centralized library between the multiple UI clients and the persistence layer.

In round-table discussion it was suggested that maybe we could leverage this into the existing notes functionality. Now, while I may have described these two systems in a way that that makes them sound quite different, consider why it might on the surface seem appealing to blend them. First, we have an existing and functional system that already performs a simple version of creating and emitting a message. Moreover, the notes module relates its content to all of the entities considered by this new task notification system. It is natural to think the two could be married somehow. They shouldn’t though. This is an excellent example of Separation of Concerns – a concept often relating to classes in object-oriented design. Loosely interpreted, SoC suggests that one should avoid building complex and loosely-interdependent functionalities into a single class or functional set of classes. Instead it is better to break out these functionalities into constituent parts and allow them to interact as distinct units. In other words, the fact that notes and notifications share some common threads is not compelling enough to consider merging them.

The thing is, I remembered at the time that the notes system was first discussed there was minor awareness that a task notification system could be on the horizon. At the time I recognized the similarities and lobbied to build a more complex system that would be flexible and extensible enough to not only take care of the immediate notes need but also get a two-for-one by laying the foundation for the eventual notification system. Sure, it would mean more development time but could save us time later. Ultimately the decision was to go with the simple, closed system that did only what was required for notes. In hindsight this was the right move because we wound up with a quickly developed system that did exactly what we needed and also allowed for time to better flesh out the details of exactly what the use cases are for the notification system (recall it was all conceptual at that time, not issue-driven).

The notification project has gained steam only because of a small subset of current needs. There are however many conceptual use case variations I can see that are almost certainly going to arise once this is implemented — things such as multiple co-recipients, passive notifications (i.e. no task, just information), chained approval and automated alerts. This is the kind of software solution where a manager uses it and then thinks of three other ways it could solve other problems. Hell, I’ve already come up with a few for our department and its not even made yet. So I see a small amount of irony in that we are yet again faced with the question of staying tight to the immediate need or put in hooks for eventual permutations. And yet again I am lobbying to consider the bigger picture.

Only this time I think I’m right, and here’s why.

The notifications system is going to require some sense of a “model” that defines the rules or configuration of the process from end to end. This model will be used as a basis for a designer that can be used to essentially build an instance of the model. That instance is what becomes persisted and is sent to the individual user queues, encoded with all the information required to perform the necessary actions. When dealing with such a model-based system there is a distinct advantage to using interfaces to define the members (methods and properties) of the model’s components. Interfaces allow you to build the system independent of concrete classes, thus decoupling the conceptual aspect of the system from the implementation.

In other words, let’s say a notification has a property called ‘Sender’ of type Person — this is the person who creates the notification. The type Person should have a name, maybe a user ID and let’s throw in a title for the sake of diligence. All these values can be used by the presentation layer to assist in identifying the sender to the recipient. Works for our narrowest use case. Now, let’s say the very next use case to come after release is that we have a database job send alerts out to multiple recipients. Is a DTS job a person? No. Can we cram it into that box? Sure! The name can be, um, ‘System Process’ (hopefully we did not break it out into first and last name properties). UserID? Heck, let’s make it zero or a random GUID if you prefer, but either way it does not reflect the same ID system that internal users are identified by. Great! What’s next… Title. Um… oh, forget it! This is just terrible design and painful to watch unfold. Consider that we would also need to support a collection of recipients as well. Refactoring that would be a bear.

In my opinion the best way to address these almost certain coming issues is to plan for them now. Having a Sender be an IActor interface allows for inherent multiplicity. Instead of Name (or FirstName, LastName) we could have a generic property called DisplayName. UserID can extend to ActorID and we only need a mapping table to assist in bringing together disparate ID systems. Now we can still have a Person class used when it is a real employee, but we can also have a DtsJob class as well, and they can both work equally as well because they only need to implement IActor and satisfy the required members of that interface’s contract. Taking this a step further a notification’s sender and recipient can be defined as IActor objects, so the concrete types become irrelevant to the conceptual requirement that something initiates the notification and something receives it or is assigned to it. Heck, now we can have mutiple IActor recipients as a collection with virtually no effort and we can support a few more use case scenarios.

Oh, and by the way, notes can be retro-fitted to this model if the need ever arose. The IActor recipient could be the notes repository which programmatically would process the note generation. See, the notes system is just a specialized case of the larger notification model. It made no sense to build notes with this interface system because of time constraints but also there was only one known implementation of the model. Now that we have two and many more coming it is imperative that we switch to an abstract system of interfaces because otherwise any new requirements will likely incur significant refactoring or code duplicate — and those are resource costs that only get higher with each revision.


The null object pattern in use

April 16, 2011 Leave a comment

What is the null object pattern and why should you care? Well, if you’re a masochist who likes to add superfluous validation code to any give project or if you are an obsesive compulsive about adding such superfluous code… then I suppose you wouldn’t care. However, for the rest of us this can be a quite useful design pattern that can lead to simpler code that is more maintaianable and better testable. That covers the why, so here is the what in a nutshell.

Design patterns provide an architectural or algorithmic set of steps or procedures to solve specific programming design issues. This design pattern addreses the common issue with .NET development where an instance of a class, or a reference object, is tested for having a null reference before using the object in code. Why would you do this in the first place? Consider that if you attempt to access a method or a property on a reference object that is null (or Nothing in VB.NET) you will encounter a nasty NullReferenceException. This is not the type of error you would want to introduce to your user, but even if you are savvy enough to catch such an error before it crashes your application you are still posed with the issue of restoring the normal flow of operation for that application in light of this unexpected error. Read more…