OOP and the QSM

[MartinMcD]

Hi there,

I have developed an application using the event-driven QSM pattern. However, where in the past my main state machine would contain the usual collection of sub-vis I have implemented an OOP solution.

It has been a bit of a learning curve but I'm very impressed so far with the benefits. I have 5 classes looking after FileIO, plotting an FFT etc. It all works nicely.

My question is one of elegance I think... This is an example scenario:

- The user selects Settings->FFT Settings... from my custom menu

- This action is picked up by the event handler which enqueues an enumerated state 'getFFTSettings'

- This request is picked up in the state machine and in the getFFTSettings state I unbundle the FFT class object and pass it into and out of the 'cFFT:getSettings' public member and away we go - a dialog box pops up, populated with the current class data and giving the user the option to change it etc. All fine.

What I'm wondering is whether this is a sensible way of doing things? I have lots of states in my state machine to handle all sorts of different things, it all works nicely but the 'loveliness' of the OO implementation seems to be reduced by having the extra step of the state machine.

Am I worrying about nothing or is there a design pattern that I should be reading up on which could help me build a better solution?

Any thoughts would be great - just pointers on things I should be reading up on would be smashing.

Thanks very much,

Martin

[Daklu]

Am I worrying about nothing or is there a design pattern that I should be reading up on which could help me build a better solution?

Any thoughts would be great - just pointers on things I should be reading up on would be smashing.

Not a specific design pattern, but if you are just starting out in OOP Head First Design Patterns is an excellect starting point. Head First Object-Oriented Analysis and Design is not quite as good but still a worthwhile read. It focuses more on the entire software development process rather than just OO design patterns. Some books that offer different slightly different perspectives are Design Patterns, Object Thinking, and Practical API Design.

By far the best thing you can do write software trying out different things. Keep going with what you've got until you reach a limitation of your design. Then figure out why your design doesn't work, refer back to your books, and see if you can come up with a better solution.

As for your specific design, I'd ditch the QSM, but that's just me...

[MartinMcD]

Fantastic, thank you, Amazon will be sending me a copy of Head First Design Patterns very shortly.

I've trying to get my head around how I can ditch the QSM, which I'm keen to do for a learning-exercise if nothing else, but can't get my head around it at the moment - I still need (I think) a UI and a 'doing things' loop to keep the responsiveness in the system, each time I think about it I just end up at the QSM-with-OOP again. I shall keep thinking & reading...

Thanks again for the tips.

[Daklu]

I've trying to get my head around how I can ditch the QSM, which I'm keen to do for a learning-exercise if nothing else, but can't get my head around it at the moment - I still need (I think) a UI and a 'doing things' loop to keep the responsiveness in the system, each time I think about it I just end up at the QSM-with-OOP again. I shall keep thinking & reading...

Yep, if you want the UI to be responsive you will always need multiple threads. A UI thread (loop), a worker thread (loop), and a mechanism to exchange data are the minimum functional blocks required. The Labview QSM is usually implemented as a variation of the Producer-Consumer pattern; however, all implementations that have a UI loop and a worker loop are not necessarily QSMs. Multiple loops are not the problem--the problem with QSMs is they do not adequately separate the three functional blocks. How do you know if your implementation is a QSM? If your worker loop is directly manipulating the message queue (other than dequeuing one message at a time) then you probably have a QSM. There's a long thread discussing it here. There was also a discussion on the dark side within the last couple weeks but I'm at a loss trying to remember where it was.

If you want to get out of the pattern of having the UI loop and the application's worker loop on the same block diagram, the Model-View-Controller architecture is a good place to start. It has the benefit of completely separating your application's UI from your application's functionality. As always, there is a tradeoff. MVC requires more framework code than the simpler "single module" design most often seen. Note that in my MVC designs I still have many vis which have multiple loops, usually one loop to receive messages from an external source (be it other code or a UI) and another loop that provides the functionality and sends messages out.