LVOOP vs. Scripting

[Cat]

You may use Notepad++ that support C++ syntax.

And it's green!

[Daklu]

After you finish that book I suggest picking up Head First Design Patterns. The way it presents information may lead you to believe it's a throwaway book but it has surprisingly deep explanations of design patterns. Each chapter often starts with application requirements and a naive implementation. Through the chapter the code is refactored and functionality is added until you end up with an implementation of the design pattern. This technique really helped me understand the problems each design pattern addresses.

A word of caution: Expect to make lots of mistakes designing your first several object models. They will be design mistakes, not implementation mistakes, so it will take more time to fix them. Be sure to give yourself extra time to deal with them. And try to resist the temptation to immediately rewrite your reuse library as classes.

[crelf]

A word of caution: Expect to make lots of mistakes designing your first several object models. They will be design mistakes, not implementation mistakes...

That's great advice!

[Cat]

After you finish that book I suggest picking up Head First Design Patterns. The way it presents information may lead you to believe it's a throwaway book but it has surprisingly deep explanations of design patterns.

Thanks for the suggestion. Some of the reviews I've just read say you need to know Java to understand the examples. OO Thought Process has examples in both C# and Java. I can read the C#, but everytime I look at the Java, all I can think is, "That's not code, that's just somebody talking about code." Think this will be a problem?

A word of caution: Expect to make lots of mistakes designing your first several object models.

My guess is that when I think I've got something workable, I'll post it to the LVOOP subforum, and let you guyze rip it apart and tell me how it *should* have been done.

[ShaunR]

"That's not code, that's just somebody talking about code." Think this will be a problem?

Not at all. Just replace the word "code" with " an object" in your sentence and thats pretty much OOP.

[Daklu]

Thanks for the suggestion. Some of the reviews I've just read say you need to know Java to understand the examples. OO Thought Process has examples in both C# and Java. I can read the C#, but everytime I look at the Java, all I can think is, "That's not code, that's just somebody talking about code." Think this will be a problem?

No, I don't think so. I had never even looked at Java code before buying this book, so I just considered it pseudocode. I wouldn't worry too much about the syntactical details in the book; Labview's version of OOP is different enough that no text language implementation translates directly into Labview.

[Black Pearl]

All these must read books lead me to think, that OOP gives your software a lot of overhead. Not the code, but the design.

Felix

[PaulG.]

All these must read books lead me to think, that OOP gives your software a lot of overhead. Not the code, but the design.

Felix

Indeed. The more I read and understand OOP the more I believe it's practical only in large applications or applications that could become large. And then OOP would be essential.

[Black Pearl]

I don't think it is essential. The thing that is essential (for large app's) is encapsulation. We can achieve this by other design concepts, such as Action Engines.

The most important concept of OOP that I don't see a solution without OOP is inhertance. And this concept gives you a whole new way of creating reusable code (There was a great reply by Ben on NI forum about it).

And this would be my path of learning OOP, treat it as the glorified cluster and try to get a more reusable code from it. But the warning above really sounds important to me: Don't start OOPing your reusable library.

Felix

[crelf]

All these must read books lead me to think, that OOP gives your software a lot of overhead. Not the code, but the design.

What you loose in design time you gain (if not, moreso) in coding, integration and testing time. Your first few designs will take some time, and you might think it wasted, but remember your first state machine? You have to think about that up front before you coded it, and now you are probably much more efficient at putting them together because you more intmately understand state machines, and have the experience implmeneting them - getting in to OO is exactly the same. There will also be some OO concepts that you think are time wasters (like writing methods to expose private data outside a class), but once you play with it for a while and really understand why it needs to be that way, you'll never look back.

The more I read and understand OOP the more I believe it's practical only in large applications or applications that could become large.

I can't disagree more - in fact, probably 75% of my OO has been little nuggets that are used by large non-OO architectures. Sure, a lot of the examples you see are of large apps, but IMHO that's no way the be-all and end-all of OO. For example, I'm currently writing a snippet of code for a partner of ours that have their own sequencer written in LabVIEW (don't go there ) - my snippet's input is a reference to the table on their FP that contains all the steps and their descriptions, and my output is a picture indicator that is a flow chart representation of the sequence. With OO, it took me about a day to set it up, without OO I don't think I could have done it in weeks. Another example is the config file VIs that come with LabVIEW - they're not a large application - they're a convenient method (pun intended) for manipulating a particular type of file.

In summary: don't think about OO as it applies to the size of a project - think about how it applies to objects. If there are elements in your system that can be thought of objects, then OO is probably the right choice, whether it be the tiniest file function or the largest application.

The most important concept of OOP that I don't see a solution without OOP is inhertance. And this concept gives you a whole new way of creating reusable code... And this would be my path of learning OOP, treat it as the glorified cluster and try to get a more reusable code from it.

That is an excellent summary - nicely put Felix!

But the warning above really sounds important to me: Don't start OOPing your reusable library.

See, and now you lost me We have a bunch of OO stuff in our reuse library. What about OO means you shouldn't use it in a reuse library?

[Black Pearl]

A word of caution: Expect to make lots of mistakes designing your first several object models. They will be design mistakes, not implementation mistakes, so it will take more time to fix them. Be sure to give yourself extra time to deal with them. And try to resist the temptation to immediately rewrite your reuse library as classes.

Me: But the warning above really sounds important to me: Don't start OOPing your reusable library.

See, and now you lost me We have a bunch of OO stuff in our reuse library. What about OO means you shouldn't use it in a reuse library?

I was refering to post above. Focus is on OOP beginner. I do (will do/should do) my reusable.lib with 'stable'(I know how to design) stuff.

Well, now that the original poster is not needing this thread any more (and ist Lava Lounge), I hijack it and tell you my story of insight.

I am stuck at LV 7.1. so no OOP for ages. Got some student version, so I could do some in my private life, but why? So what I could do is to look at the abstract ideas of OOP (I did some amateur OOP with Java and delphi), read the Go4 book (ages ago) and went to wikipedia (for the Go4 patterns). And then took a time what to do without OOP, no, definitfely how to get their benifits to go into a non-OOP world.

It actually is an amazing insight on the complete idea, because you are stuck or blessed with beiing able to not OOP.

As I said above, the biggest issue of reproducing OOP code (yes, I unsuccessfully tried coding) is that you miss inheritance. (This is very focused on the enum of an AE). And OOP languages are still not decided on how to finish this issue: multiple inheritance, interfaces.

Next point (solvable): text languages treat objects by ref (and LVOOP by val). I can do some of it by plain (non-OOP) LV. But it is not native of our wire logic (by val!). And that in case make it difficult to understand e.g. the Go4 Patterns of eg. Abstract Factory.

And now comes the big important point:

When/if I do OOP, hopw many Patterns I need?

Felix