LVOOP: Lesson Learned (not a question, just sharing experience)

[Ray.R]

I should have known better...  I really should...

I can't remember what I was thinking at the time..

The values were only going to be used temporarily... I guess..

But I forgot the golden rule about scalability!!

- sigh -

I implemented a project using LVOOP.  Most everything has objects, except for a 2D array of strings which was a reservoir of test categories and test selections.  I used shift registers to hold the values.  No big deal.  Was used here and there for temperary purposes until the complete selections were done.  Worked great and everyone was happy.

Then a small feature addition happened.  The ability to restore everything throughout the code.  With LVOOP, it's fantastic and simple..  Everything worked.... except..

You guessed it..  

Darn!!

Creating the object is no big deal..  But the time to refactor the code will exceed the bit of investment to have done this in the first place...

The lesson learned:  If you program using LVOOP, create objects for EVERYTHING! 

🙂

[Intaris]

Oh, I've been there and done that too.

But making EVERYTHING an Object is kinda hard.....

There has to be a practical limit drawn somewhere.  Where that limit depends onseveral factors I have not yet been able to repeatedly recognise.....

[Ray.R]

Maybe I exaggerated a little..

I think I will avoid using shift registers and use objects..  I'll see how far that gets me..

Although in this particular project, I'll have 3 remaining shift registers... We'll see how long they last 😄

[Norbert_B]

Thanks for contributing your experience.

I don't want to sound like smart-arse, but:

When using OOP (Object Oriented Programming), you have to plan your software framework using OOD (Object Oriented Design). OOD includes all aspects of an application, so it is different to a "common data flow approach". Mixing those two is never a good idea....

If you really have to implement EVERYTHING as a class.... i doubt that. But if data structures (and their usage) is prone to changes when feature additions are reasonable, you are correct that those should be classes in OOP projects....

Norbert

[Ray.R]

LOL!  Thanks for sharing Norbert.

I totally agree with you.  The funny part of the story is that I had not anticipated that the portion of the code in question would "change".  Or rather, I had not foreseen the fact that it would be needed as part of the data that would need to be restored. 

The beauty is that the experience demonstrates how well suited OOP is for scalability.  And like you said mixing normal data flow with OO can become messy, so usually not a good idea. 

I did exaggerate when I said "EVERYTHING" should be OO.  I'll see what an upcoming project (from scratch) done using OOD will become. 

[Intaris]

OOD = Object Oriented "D'OH (that should have been an object!)"

Or to paraphrase a certain film: "My God it's full of Objects"

[Norbert_B]

---

@Intaris wrote:

OOD = Object Oriented "D'OH (that should have been an object!)" 

---

That reminds me on a German saying:

Planung ist, Zufall durch Irrtum zu ersetzen.

Which translate into something like this:

Planning is to replace chance by mistake.

[Intaris]

---

@Norbert_B wrote:

---

@Intaris wrote:

OOD = Object Oriented "D'OH (that should have been an object!)" 

---

That reminds me on a German saying:

Planung ist, Zufall durch Irrtum zu ersetzen.

Which translate into something like this:

Planning is to replace chance by mistake.

---

Well there you go.  I'm speaking German for 12 years now in Switzerland and I've never come across that gem of a saying before.  Thanks for that one, I^ll be using that otfen.

[JÞB]

---

@Intaris wrote:

---

@Norbert_B wrote:

---

@Intaris wrote:

OOD = Object Oriented "D'OH (that should have been an object!)" 

---

That reminds me on a German saying:

Planung ist, Zufall durch Irrtum zu ersetzen.

Which translate into something like this:

Planning is to replace chance by mistake.

---

Well there you go.  I'm speaking German for 12 years now in Switzerland and I've never come across that gem of a saying before.  Thanks for that one, I^ll be using that otfen.

---

Bing translates as "Is planning to replace random error" (German grammar confuses me but,  "The purpose of planning is to limit random errors"?)

[hecmar.arreola]

Has there been any good books written about LVOOP yet?  Seems like there should be a "Design Pattern" oriented book for LVOOP.  I love LVOOP but even after 2 years of utilizing LVOOP features in my projects I still feel lIke I have a lot to master.

The Actor Framework seems really compelling for me to learn and master because so many of my projects have such a large scope that my current implimentations have just become LabVIEW slop over the years (feature-after-feature tacked on with very little time to do it).