GOOP - Bridging the Gap

[SeanDonner]

At the beginning of Dmitry's "Applying Agile SW Design Principals..." presentation he polled the room to see how many people came from a Computer Science background and although the video did not show the entire room, my guess is that it was a much smaller percentage compared to those who come from the Electrical or Mechanical disciplines.  I too fall in the latter camp and much of the core principals of proper CS I learned from looking at and modifying quality LabVIEW code.

I consider myself a competent, advanced LabVIEW user and I do have a passing grasp of the OO teneants of encapsulation, inheritance, polymorphism/dyanmic dispatch; but that is a far cry away from actually implementing a design using GOOP.  I have just enough knowledge to realize that his presentation was packed full of sage advice but nowhere near enough knowledge to fully understand why; I particularly failed in the UML diagrams.   What advice does this community have for those of us who don't have extensive knowledge on OO principals & design but realize they are falling behind the curve by not understanding such things?

As LabVIEW syntax continues to take on more modern-day features, I feel the divide between the formally trained CS users and the non-CS users will grow exponentially.   I've not yet found a good bridge between something any CLD should know, such as the QMH, and the Actor Framework.   Either you understand OO and "get" the Actor Framework, or you don't; and if you don't you fall back on the non-OO things you do know.  I wan't to break this cycle but I'm not sure where to start.

P.S.

I posted the above as a comment to Dmitry's TS9518 document but I think it warrants its own discussion so I'm reposting it here.

[Dmitry]

SeanDonner wrote:

At the beginning of Dmitry's "Applying Agile SW Design Principals..." presentation he polled the room to see how many people came from a Computer Science background and although the video did not show the entire room, my guess is that it was a much smaller percentage compared to those who come from the Electrical or Mechanical disciplines. 

There was about a dozen CS/SE folks in the room. I was actually expecting less. Not sure how many people attended, but it's definitely under 10%. About half of the room were CLAs and CLDs ...

I particularly failed in the UML diagrams.   What advice does this community have for those of us who don't have extensive knowledge on OO principals & design but realize they are falling behind the curve by not understanding such things?

You may be OK without learning OO Design in case your applications are small (say 100 VIs or less). However, if you want to get more productive (don't we all ?) there are two choices:

1. Practice wiring code faster than Darren Nattinger OR
2. Learn to design reusable code

That's when OOD/OOP saves the day. Out of ~600 VIs in the Boat Monitoring System application ~300 were reusable libraries (logging, error handling, message handling, etc.). The other ~240 could be reused (without changes) on a Monitoring System for a different boat. The remaining ~60  VIs either have to be 'recycled' (i.e. used as a basis for new code) or done from scratch. That's a 90% effort savings - meaning I have an upper hand in bidding on a Monitoring System contract for another boat ...

I am in the OO land for too long to remember the pain points or give specific advice for getting there. Just the common sense options :

• Read a good OO Design book (The Object-Oriented Design Thought Process)
• Start looking at Design Patterns (preferrably in LabVIEW)
• Learn a dozen of more useful ones (like Factory Pattern, Visitor Pattern, Adapter/Facade/Decorator Patterns, etc.) - this would help with understanding UML Diagrams
• Take an OO Design course
• Join a project team proficient in OO Design - the most efficient way for getting up to speed. This also makes finding a mentor easier.
• Look at design of good class-based reusable libraries (how do you figure out good ones from the not-so-good though ?)
• Look at SOLID OO Designs (shameless self promotion on my part here : Actor Programming without an Actor Framework, Error Handling for LabVIEW Architects)

I've not yet found a good bridge between something any CLD should know, such as the QMH, and the Actor Framework.   Either you understand OO and "get" the Actor Framework, or you don't; and if you don't you fall back on the non-OO things you do know.

Speaking of Actor Framework. It is an elegant and scalable design. But I think trying to learn OO by doing an AF-based project on your own is something people should avoid (Allen Smith may disagree ). Actor Framework is based on three pieces:

1. By-Value LabVIEW Classes (LVOOP)
2. Command Design Pattern implementation in LabVIEW
3. Basic knowledge of Actor Programming Best Practices

There is an easier way of developing ones LVOOP skills than learning all three at the same time - especially the Actor Programming DO's & Don'ts ...

PS: Please don't use GOOP to mean Graphical OO Programming. In the LabVIEW community it often implies NI GOOP Development Suite.

Message was edited by: Dmitry