Leaderboard

If you are not using POOP (Predominantly Object Oriented Programming) then a lot of the POOP design patterns are no longer relevant since the problem that they solve becomes trivial and most of the mechanics gets handled by the language (yes I'm looking at you "singleton"). With POOP, the problem is usually "State", transitions of state and how to manage it. That's not to say that there aren't any in non-OOP languages, They are just usually called "frameworks" and tend to be more generic. The thing to bear in mind is that design patterns solve a well known problem. But that problem is usually a restriction in the language or paradigm you are using (sometimes called "Idioms" by the Architecture Astronauts). Therefore design patterns tend to be paradigm/language specific (not all...but most). But you have probably been using non-OOP design patterns for quite some time (State Machines, Producer/consumer, Publisher/Subscriber) Take Monads for example (a functional programming design pattern) Sound like VI's and terminals? We (as Labview programmers) have no need for this "pattern" because it is an in-built feature of the language (we chain VIs [monads] together using wires [pipelines] via their terminals [bind/return operators]). A good example of a design "Pattern" that IS useful in Labview is the Producer/Consumer (we all know that one - it's a template in Labview). Why? Because it addresses a restriction of the language (it breaks Dataflow). Most of the time dataflow is our friend (it automagically handles state and imposes strict sequencing in a parallel manner) but when we need asynchronous operations this is a simple generic pattern in our arsenal. So what POOP patterns are useful to us in "classic" labview? As a general rule -.those that break dataflow! So we have a use for things like the "Observer Pattern" or, as we muggles call it, "Publisher/Subscriber". But we also have uses for the more structural patterns such as Strategy (think plugins), State (think state machine) and Facade (think API). although these could arguably be called "idioms" for classical Labview usage. And those that aren't very useful? Well. Most of them Labview itself makes most of the issues associated with POOP patterns fairly trivial. Many are variations on a theme (Mediator and Facade for example). Many revolve around instantiating objects - Creational patterns (we generally define all objects at design time). And many are based around managing communications between objects - Behavioral patterns, (we have wires for that). Why aren't there many references to design patterns outside of POOP? Because they generally solve problems caused by POOP. Now where's my hard-hat.

So I can make all my bugs go away by simply describing the behavior in mydocumentation? Awesome!

You just wanted to say "poop" multiple times, didn't you?