Singleton Schmingleton

[swatts]

I'm such an adult! but the title made me laugh so it stays.

AristosQueue presented "Various Tangents Around The Circle of Design Patterns" and as usual it was a well thought out, extremely well presented and original piece of work. Sadly it wasn't recorded so you will have to take my word for it.

Now I've said all these nice things I'm going to discuss one of the ideas presented and my starting position is that I'm not entirely sure a component as defined in LCOD is actually a singleton pattern at all....

I have a very early edition of the GoF book and I actually was pretty keen on patterns when I was researching our book. Sadly my edition of Design Patterns is in almost perfect condition. This tells me only one thing....I didn't find the book very useful or applicable to LabVIEW, this is where AQs talk of idioms comes into play I think. My opinion is that the patterns described are idiomatic  to C++/Java and they help deal with a lot of the heartache and nause related to those languages. I strongly believe LabVIEW has it's own idioms.

The Singleton Pattern Defined (by wikipedia)

In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects. The term comes from the mathematical concept of a singleton.

There is criticism of the use of the singleton pattern, as some consider it an anti-pattern, judging that it is overused, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application

and here's a pretty good definition..

"Ensure a class has one instance, and provide a global point of access to it." (Note: I was too lazy to read the book again so swiped it from this excellent article http://gameprogrammingpatterns.com/singleton.html)

For us a component/action engine is purely there as a high level construct to restrict access to related modules in a program. This is design construct aimed purely at simplifying the block diagram. So for example here is a component as defined by us, this is an oscilloscope and the customer requires the ability to have either NI racks or Agilent with a variety of oscilloscopes.

Note: I'm still wrestling with the Acqiris Cards, they will hopefully be an AcqirisScope subclass as per the NIScope class.

As we can see there is little relationship to a singleton pattern here, rather the component is a restricted interface to a group of related objects. So what is the point of this? I think this is where AQ and I are converging (this is not a static situation, because we are analyzing designs at greater depth, publishing our ideas and discussing them).

I will talk about this convergence in greater depth in my next article, for a preview sneak a peak at the conversation here

Lots of Love

Steve