WebPart Contract Programming (Design by Contract)

I am a believer in Design by Contract (DbC) programming paradigms while designing WebParts. Maybe because I have just seen so much SharePoint development with the loosest programming standards (ahem, CorasWorks I am looking at you), where the development was done just enough in order to render out the functionality so that it just existed (I will expand more of these grips later). When learning a new large OM (as is SharePoint) and integrating it into your custom development, I will bend and say that I can understand that, for a period of time. But, WebPart development should adhere to the same standards as traditional .NET development, no less (with, obviously, some exceptions that I won’t go over here). It is not acceptable either within in-house development or when doing turn over client development to just develop components such as WebParts so that they just work and not take into account any type of programming standards.

This is subject is obviously exceptionally different than implementing an appropriate SDLC (Software Development Lifecycle) into your environment (although DbC does lend itself rather well to JAD [Joint Application Development]) in order to brick-build future pluggable software components), promoting more appropriate TDD standards, or other aspects. As a vast side note, and now as a person that is whole heartily on the bandwagon, mock objects really do support a higher level of TDD and really bumped the quality of unit testing that I now do. Because of the amount of external dependencies that tend to exist within SharePoint development, I was initially really looking for something like mock objects to allow a more practical way to implement my unit testing schemes. I looked at a few different packages, and IMHO, the RhinoMocks framework was the best. I would recommend it because of its middle of the line architecture that assimilates the benefits of a variety of the mock framework thought patterns.

Getting back to the subject of this post…

This post originally spawns from the BioPoint SDK (you can read more about the SDK and get the API documentation here), along with some other freeware that I release on the site, where people have noticed within the SDK documentation that there are interfaces for each property, etc., which is noticeable in practically in every WebPart class that I write, usually in order to build out these types of property contracts. Regardless of whether I am doing the development for free, for contract, or for my full time job, when I do SharePoint development, particularly for WebParts, you will see interfaces.

Why do I approach .NET (or OO to keep it even more abstract) development, and, even more specifically, SharePoint WebPart development like this? That is a great question, and I really hope I am not the only one that takes this type of approach, I can’t imagine that I am because it is so freakin common.

WebPart Contract Programming (DbC programming paradigm) is basically another way of strongly defining contracts (policies) by heavily relying on the use of interfaces between WebPart classes; this has been around before we even dabbled into managed SharePoint development. Using DbC allows the defining of patterns which will in essence allow a WebPart class to inherit from a derived interface, that, upon implementing the arbitrary interface, allow the concealment of certain WebPart class behavior. Using DbC one can define a WebPart class and the interface, by which the interface will in essence build a policy that, will control the behavior of the WebPart class, while the behavior of the class that the interface is sponsoring is not visible.

Going back to my example in the beginning where I was talking specifically regarding WebPart properties, once the interface is defined it must be implemented within the WebPart class to expose the relevant WebPart properties. In this structure, the WebPart class will derive from the interface and will provide the actual implementation of the get and set methods of the properties (used to define something like a set of constants that are related to the WebPart, and can be something as remedial like parsing out a string of text or something to the HTML stream).

This all sounds great, but what is the benefit of all this non-sense. What can I tell the suits (if this is your first time reading this blog, that is what we call management) why I am spending an extra 5 minutes building out interfaces for our internal SharePoint development (it really does take this long).

The two main reasons that DbC is great for WebPart development is because it allows a high level of re-use (as the public interfaces can  segregate implementation and allow multiple pieces the pieces the option to tap into the interface quite easily, which helps when developing components that are heavily going to be re-used within SharePoint. This is exceptionally common when developing corporate shared libraries that are tapped for internal development RAD (Rapid Application Development) modularization, I can build functionality out in public interfaces, and future developers will have access to it, thereby just exposing the implementation.

Secondly, I prefer the use of DbC approach when developing WebParts since when using component type design, you are hiding public implementation and therefore there are no changes that are required for the public interfaces. This also promotes the amount of re-use that you will procure when you have a consistent, solid interface, heightened by the fact that interfaces are heavily polymorphic and can allow the delegation of duties between objects, obviously objects of a similar nature.

This was just a brief introduction I guess to settle some of the qualms of way some of my code looks like it does. Is it right? I dunno, its just how I do it. I wrote this blog post so quick, hell, I don’t even know if it is accurate.