Valorem Consulting

| Tags: Evan Lang, Silverlight, WPF

originally posted by Evan Lang: (link) - please comment at original post

I’ve been spending more time recently focusing on design patterns. Basically I’m just looking to add more clever tricks to my developer sack-o-tricks.  The best way to think of patterns, in my mind, is just an elegant solution to a common problem. When I run into an interesting problem I need to solve, I do my best to implement some logical pattern that solves it. If I can generalize my solution so it has a chance of being useful for other things, cool.

In the wide world of patterns, however, there roam strange troll-like creatures usually referred to as pattern “purists.”  Why they exist is generally unknown, but these consist of people who will condemn, deride, or disregard any pattern unless it fulfills all of the following requirements:

  • Works multithreaded
  • Works across DLL boundaries
  • Fits well across all layers of any N-tier application
  • Works elegantly on any imperative language ever made. Ever.
  • Usage is immediately obvious to even the dumbest of code monkeys who look at it for the first time (and believe me, we will find the dumbest and try it out)
  • Costs zero memory to store, and consumes zero clock cycles to manage.
  • Has no environmental dependencies (whether they be other DLLs, a particular browser, operating system, or transistors and wires)
  • Feeds starving children in Africa
  • Puts satellites into orbit
  • Specifically puts a satellite into orbit that drops food on children in Africa

Given these requirements, it’s easy to see that there aren’t actually very many real patterns out there. It’s also easy to see why, in terms of personal appeal, pattern purists generally rank right down there with macevangelists (who are the single best reason to not use a Mac). Personally I’m content to continue using my fake patterns as they have an uncanny way of actually solving my problems. But in an effort to appeal to the purists, I set out to design a pattern to meet all of their requirements. A pattern that can be used anywhere and applied to any problem. I call it the Object Pattern.

One little disclaimer is that I didn’t succeed. My pattern not only depends on wires and transistors… you actually need a whole computer to make use of it.  And the language needs to be object-oriented.  Also, it may have killed some kids in Africa with its satellite… I guess loading it with jawbreakers wasn’t the greatest idea (wait, are they food? Maybe that was the problem.) But I got pretty darn close, so here it is.

Anyway, to see the Object Pattern in action, let’s take a look at an implementation in C#. The pattern exposes a unique self-referencing quality that permits greater access to a member’s fields, properties, and methods, which can then be used to implement project-specific solutions.  This feature is exposed through the following class, which must be inherited to properly implement the pattern:

public class UniqueSelfReferencingInstance<T>
    public T Me { get { return (T)this; } }

Now let’s see it in action. I declare a class HamSandwich, which will need to figure out its weight based on the amount of condiments on it.

class HamSandwich : UniqueSelfReferencingInstance<HamSandwich>
   const double bread = 0.05;

   double mayo;
   double ham;

   double cheese {get;set;}

   double TotalWeight()
      return Me.ham + Me.mayo + Me.cheese + Me.bread;

   public MyClass()

As you can see, the Object Pattern has made accessing fields, properties, consts, and even methods a breeze. Now that the developer has full control over these constructs, they can be used to implement solutions to whatever problems he may face down the road. The pattern is completely thread-safe, as the Me property is constant over the life of an object. Even across DLL boundaries, once you have access to a UniqueSelfReferencingInstance object, you can acquire the Me reference. Furthermore, the pattern can be applied to any object-oriented language, and is guaranteed to work on any platform that you can compile it to.

The neutered, broken patterns I often use to solve programming challenges will never live up to the laudable ivory-tower idealism of the purists, so I hope to see more use of this pattern and ones like it in the future, that can meet the exacting standards of our captains of software engineering. Similar concepts to watch out for are the Multiple Instanced Singleton Pattern (MISP), Loose Collection Pattern (termed ‘loose’ as there is no collection per se, but it exists implicitly through references your application makes to its various members… useful because the collection automatically resizes when an object is garbage collected; downside is that it is not enumerable), and the Actual Interface pattern (which returns a reference to an “actual” … an object that serves as the true instance and worker bee of the interface).

So keep an eye out! Real software is just around the corner, on the bleeding edge! Soon nuisances like compatibility, platform dependency, and testing will be a thing of the past!

Remember to please comment at original post: (link)

2018 IdentityMine, Inc. Privacy Policy