Non-OOP Design Patterns

[Cat]

I would really like to find out more about the concept of design patterns. But every time I look at some reference, it's all within the context of OOP. And I don't do OOP ( ). I can't imagine that no one thought about design patterns before OOP came along or that design patterns aren't possible without OOP.

Does anyone know of any books, websites, etc out there that talk about specific design patterns, without making the reader wade thru OOP?

[Yair]

Try going for the de-facto standard - http://www.laputan.org/mud/

[PaulL]

Hmm..., I'm not sure how much like you will have, at least with the specific term "design pattern," since Gang of Four introduced the term (if not the larger concept) in an Object-Oriented context. In any case, this looks like it might a good place to start: http://en.wikipedia.org/wiki/Design_pattern_(computer_science) .

(It might be easier to learn a little about OOP.) You're right, it's nontrivial to get started with OOP. I wouldn't go back, though! Maybe there will be something even better than OOP around the corner?

It certainly is true that it is possible to implement some of the concepts and some of the patterns in nonOOP terms. I don't know that there will be much literature on that, though....

[crelf]

(It might be easier to learn a little about OOP.) You're right, it's nontrivial to get started with OOP. I wouldn't go back, though!

C'mon Cat, jump into OOP! The NI OOP course is quite good (based on Endevo's course), and once you "get it", you'll never go back.

Otherwise, LabVIEW: Advanced Programming Techniques and LabVIEW for Everyone have some good stuff in them, but you're really limiting yourself by shunning OO.

[ShaunR]

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)

The monad acts as a framework, as it's a reusable behavior that decides the order in which the specific monadic functions in the pipeline are called, and manages all the undercover work required by the computation.^[3] The bind and return operators interleaved in the pipeline will be executed after each monadic function returns control, and will take care of the particular aspects handled by the monad.

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.

[mje]

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

[drjdpowell]

And I don't do OOP ( ).

Are you sure? Have you ever used the "design pattern" of having a type-def cluster and a set of subVIs that act on that cluster? With the cluster going in the top left terminal and out the top right? Because that is the basic design pattern that is LVOOP. Looking at a long list of impenetrable "design patterns" makes OOP look like its impossibly hard to start with, but actually it's very easy to start using as a cleaner, better way to do this important pattern you already do in LabVIEW. I recall in a conversation somewhere with someone saying that a big advantage of LVOOP is the ability to customize the appearance of the wires. Some people thought they must be joking, but I understood and agreed completely. LVOOP formalizes and supports the "type-def cluster" design pattern.

A less-common LabVIEW pattern is to allow the same set of subVIs to act on related, but different, "things". If I recall correctly, ShaunR uses this pattern in his Dispatcher/Transport code to allow use of either TCP, UDP or Bluetooth as a communication method in a common set of VIs. I don't remember the method he uses (there is more than one way), but this is another design pattern that LVOOP makes cleaner and also more powerful (through "inheritance"). Inheritance is harder to get comfortable with, admittedly, but that's because this design pattern is harder to grasp regardless of how it's done. LVOOP makes it easier to do and more widely applicable (and thus you can make use it more often).

Starting with those two patterns (or even just the top one) which you are likely already using is an easy way to get started on LVOOP.

-- James

[Daklu]

...but you're really limiting yourself by shunning OO.

I agree. The market for LV developers started changing the day LVOOP was released. It's been slow to catch on, but the mindshare is growing. Not learning it reduces your future marketability and opportunities.

[Olivier Jourdan]

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.

One thing that OOP helps to solve is the team work. OOP has "rules" that you must follow, when these rules are well known, you reduce dramatically the need to write documentation on how access data, how share source code, how organize your VIs, etc... Also rules are better followed when they come from "nobody" (OOP is not a guy in your team) than if they come from one man in a team. This avoid most of quarrel in a team...

[drjdpowell]

One thing that OOP helps to solve is the team work. OOP has "rules" that you must follow, when these rules are well known, you reduce dramatically the need to write documentation on how access data, how share source code, how organize your VIs, etc... Also rules are better followed when they come from "nobody" (OOP is not a guy in your team) than if they come from one man in a team. This avoid most of quarrel in a team...

Only, presumably, if the team agree that OOP is a reasonably good set of rules. I doubt ShaunR will be much impressed with this argument.

[Olivier Jourdan]

Only, presumably, if the team agree that OOP is a reasonably good set of rules. I doubt ShaunR will be much impressed with this argument.

I'm not trying to convince ShaunR, I'm just sharing my experience with OOP I've been working with LV for a few years now, and moving to OOP has been for me a great thing. That's not a reason to not understand ShaunR argument. I've"liked" is post, anyway I think is way of thinking reach limits when you work in a team.

[drjdpowell]

I'm not trying to convince ShaunR...

Why not? He's got his hard hat on.

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")...

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.

I disagree, Shaun. Those confusing lists on wikipedia don't seem to contain any design patterns that solve problems caused by OOP. Take the "Creational patterns" list, for example. "Lazy Initialization", "Pool", and "Prototype" are things that aren't OOP specific (they can be done in non-OOP LabVIEW) and aren't solving OOP problems. The Factory/Builder ones seem more OOP specific, but they aren't solving OOP problems, they're doing things not easily done without OOP (one could argue against their usefulness, but they are optional, and one doesn't need to learn them to use OOP to improve ones LabVIEW). "Singleton", as you say, is more easily done in non-OOP LabVIEW, but I would suggest that that leads to it being used far too often. How many "Action Engines" actually have a real reason to be Singletons? The advantage of the "Singleton pattern" for the LabVIEW programmer is consciously thinking about where NOT to use it.

I do admit that one can take OOP and become an Architecture Astronaut, and I've certainly seen code that is well beyond my ability to understand, but there is plenty of down-to-earth advantages below the stratosphere. Just simple inheritance, by itself, is a great advantage.

-- James

Edited October 18, 2011 by drjdpowell

[crelf]

I don't do OOP

You ever used DAQmx? Ever read keys out of an ini file using the VIs in vi.lib? I'm guessing you do do* OOP, just without knowing about it.

* wow - "POOP" and "do do" in the same thread - real mature LAVA!

[ShaunR]

You ever used DAQmx? Ever read keys out of an ini file using the VIs in vi.lib? I'm guessing you do do* OOP, just without knowing about it.

* wow - "POOP" and "do do" in the same thread - real mature LAVA!

Just because you use a class, doesn't make your program an object oriented design any more than passing a value from one function to another makes it dataflow.

[Cat]

Try going for the de-facto standard - http://www.laputan.org/mud/

Thanks for the link. One of the reasons I'm looking into all of this is because I have a large plug-in that is on the verge of becoming a Big Ball of Mud.

[Cat]

Hmm..., I'm not sure how much like you will have, at least with the specific term "design pattern," since Gang of Four introduced the term (if not the larger concept) in an Object-Oriented context. In any case, this looks like it might a good place to start: http://en.wikipedia....omputer_science)]http://en.wikipedia....omputer_science)[/url])

Thanks, I had found the "Design patterns" wiki page, but not the "Design patterns (computer science)" page.

[Cat]

C'mon Cat, jump into OOP! The NI OOP course is quite good (based on Endevo's course), and once you "get it", you'll never go back. Otherwise, LabVIEW: Advanced Programming Techniques and LabVIEW for Everyone have some good stuff in them, but you're really limiting yourself by shunning OO.

If the OOP course was ever offered in the DC area, I would take it (ditto Advanced Architectures).

I have LabVIEW: Advanced Programming Techniques, but it's the 2001 version. I'll see if I can get ahold of a copy of the newer version.

[crelf]

I have LabVIEW: Advanced Programming Techniques, but it's the 2001 version. I'll see if I can get ahold of a copy of the newer version.

There's a newer version? I'd heard that they were working on it, but didn't know it was published.

If the OOP course was ever offered in the DC area, I would take it (ditto Advanced Architectures).

I'd tlak to your local DSM, or maybe even ping some trainers directly (Nancy Hollenback and David Corney spring to mind) - my understanding is that if you can get a minimum number for a course, NI will teach it (hey, that's how Nancy got a week in sunny Sydney about 8 years ago, when she taught me the Advanced Course).

[Cat]

There's a newer version? I'd heard that they were working on it, but didn't know it was published. I'd tlak to your local DSM, or maybe even ping some trainers directly (Nancy Hollenback and David Corney spring to mind) - my understanding is that if you can get a minimum number for a course, NI will teach it (hey, that's how Nancy got a week in sunny Sydney about 8 years ago, when she taught me the Advanced Course).

I've talked to my local DSM, and to Nancy at NIWeek last year. Getting more people to take the advanced courses is the issue. Either that or Nancy just doesn't want to come to hot/humid or cold/rainy DC.

I guess I should ping the DSM again.

Oh, and the 2nd edition of "LabVIEW: Advanced Programming Techniques" is from 2006. Do you think they're working on a third edition??

[crelf]

Oh, and the 2nd edition of "LabVIEW: Advanced Programming Techniques" is from 2006. Do you think they're working on a third edition??

No, that sounds about right. I might have to get my hands on a copy. I thought the first edition was quite good - am looking forward to seeing what they came up with in the 2nd.

[Cat]

Why aren't there many references to design patterns outside of POOP? Because they generally solve problems caused by POOP.

Well, Shaun, I threw you a soft ball and you lobbed it out of the park.

Seriously, thanks for the comprehensive reply.

Reading about Architecture Astronauts made me wonder if that's not part of my problem. I know I need to spend more time on upfront design, but at some point my attempts to keep my software generic and reusable have led me off into spending a lot of time getting more and more abstract in my design. And whenever I sit down to code it up, all that I can think is how overly complicated it all is.

As I've said in the past, I don't sling the computer science lingo. So your point that I'm already using designs is a good one. I just don't generally say to myself, "I think I'll use a Producer/Consumer design pattern here." I say, "I ought to feed this loop that's doing a bunch of stuff on command with a queue in another loop." So thanks for all the links to the right names and algorithms. That's important to know.

[Jordan Kuehn]

I've talked to my local DSM, and to Nancy at NIWeek last year. Getting more people to take the advanced courses is the issue. Either that or Nancy just doesn't want to come to hot/humid or cold/rainy DC.

I guess I should ping the DSM again.

Oh, and the 2nd edition of "LabVIEW: Advanced Programming Techniques" is from 2006. Do you think they're working on a third edition??

Not sure if this is the same thing under a different name (I don't have the material you mention), but "Advanced Architectures in LabVIEW" is from 2009. Even if it's not the same, I'm sure a lot overlaps.

[Tim_S]

And whenever I sit down to code it up, all that I can think is how overly complicated it all is.

Here here.

As I've said in the past, I don't sling the computer science lingo. So your point that I'm already using designs is a good one. I just don't generally say to myself, "I think I'll use a Producer/Consumer design pattern here." I say, "I ought to feed this loop that's doing a bunch of stuff on command with a queue in another loop."

You didn't use "thingie" or "whachamacallit" in there, so it's not a real technical description.

You describe the challenge for me when reading some (okay, many) of the technical/theory conversations is that I'm a EE who has mostly self-taught programming.

Tim

[Daklu]

at some point my attempts to keep my software generic and reusable have led me off into spending a lot of time getting more and more abstract in my design. And whenever I sit down to code it up, all that I can think is how overly complicated it all is.

My theory is that is part of the natural process of learning how to program. I know I spent some time over-abstracting the code I was writing while learning how to LVOOP. I've seen indications on other threads that lead me to believe others are doing the same as part of their learning process.

Whenever we learn about a great new technique (inheritance, design patterns, abstractions, whatever...) we get excited and start using it everywhere we can. That's generally discouraged in programming circles, but I figure part of learning how to properly use technique x is discovering the consequences of using it. Going overboard is the only way we can find out how much x is the "right" amount. I'd much rather work with someone who makes their decisions because they've actually implemented the available alternatives than work with someone who makes decisions because that's what the book (or forum, or expert) said.

(And I'll go so far as to say any programmer worth his salt has thought the exact same thing many times through their career.)

I just don't generally say to myself, "I think I'll use a Producer/Consumer design pattern here."

I don't either. I used to, but I now believe that's the wrong way to go about it precisely because it leads to too much abstraction. My thought process while coding is more along the lines of yours. "Hmm... this loop is responding to messages but I need it to send a status update every 2 seconds. How should I do that?"

[drjdpowell]

I just don't generally say to myself, "I think I'll use a Producer/Consumer design pattern here." I say, "I ought to feed this loop that's doing a bunch of stuff on command with a queue in another loop."

I don't do a lot of thinking about "design patterns" when I'm coding either. Instead LVOOP extends my ability to think things like "these operations are closely related, I ought to make a simple class and inherit from it". That statement is not more complex than inter-loop communication.

As I indicated before, I think one is better off just starting to use LVOOP as "type-def clusters+" and start exploring a (very small amount of) inheritance, LONG before ever reading about a "design pattern". Even now, the only "named" design patterns I've used are the "Decorator Pattern" and the "Command Pattern". Technically, I've probably used a few others, but independently of actually reading about them as "Patterns" (as, probably, have you).

-- James