Classes about classes

[Cat]

I'm thinking about taking the NI OOP class. It appears I've missed the cruise, so I'll have to settle for a regular ole office building.

I stopped programming in C about the time C++ was getting popular, so I don't know much about object-oriented programming in general. Every time my cow-orker who is a C#.NET, etc whiz tries to explain it to me, it sounds like he's talking about ways of accessing typeDef-ed clusters with data and their associated info. It must be more complicated than that. I looked at the LV OOP stuff back when it came out in 8.2, but it seemed like it was adding code on top of what I was already doing. Once again, I assume my lack of knowledge is the problem.

My question is this: Do I need to learn C++ before I take the NI OOP course? I've read thru all the doc links I can find on this site and they've managed to underscore how little I know about the basic language of OOP. If they teach the class in that language (ie, here's how you all did it in C++ and now here's how we'll do it in LV) I'm sure I'll manage to stumble along, but won't get as much out of the course as I possibly could.

Any thoughts?

[Antoine Chalons]

QUOTE (Cat @ Mar 19 2009, 01:27 PM)

I stopped programming in C about the time C++ was getting popular, so I don't know much about object-oriented programming in general. Every time my cow-orker who is a C#.NET, etc whiz tries to explain it to me, it sounds like he's talking about ways of accessing typeDef-ed clusters with data and their associated info. It must be more complicated than that. I looked at the LV OOP stuff back when it came out in 8.2, but it seemed like it was adding code on top of what I was already doing. Once again, I assume my lack of knowledge is the problem.

More or less the same for me.. never type a line of textual language -not one- my father taught me LabVIEW when I was around 15yo.

I didn't study computer science but thermal engineering, and somehow I'm now developing industrial application with LabVIEW for work.

I think I miss some general knowledge about software engineering and OOP is part what remain blurry to me.

I've tried to find an OOP or LV OOP training around Switzerland, but it's not easy.. A "C++ friend" of mine advised me to get an UML book to learn the concepts and then find a training session to learn how to implement OOP in the language I like (LabVIEW of course in my case).

Anyone thinks this is good advice?

.. would advise something else?

.. knows where to find OOP or LV OOP training sessions?

[ned]

QUOTE (Cat @ Mar 19 2009, 08:27 AM)

I'm thinking about taking the NI OOP class. It appears I've missed the cruise, so I'll have to settle for a regular ole office building.

I stopped programming in C about the time C++ was getting popular, so I don't know much about object-oriented programming in general. Every time my cow-orker who is a C#.NET, etc whiz tries to explain it to me, it sounds like he's talking about ways of accessing typeDef-ed clusters with data and their associated info. It must be more complicated than that. I looked at the LV OOP stuff back when it came out in 8.2, but it seemed like it was adding code on top of what I was already doing. Once again, I assume my lack of knowledge is the problem.

My question is this: Do I need to learn C++ before I take the NI OOP course? I've read thru all the doc links I can find on this site and they've managed to underscore how little I know about the basic language of OOP. If they teach the class in that language (ie, here's how you all did it in C++ and now here's how we'll do it in LV) I'm sure I'll manage to stumble along, but won't get as much out of the course as I possibly could.

Any thoughts?

Actually, it sounds like your coworker gave you a pretty good simplified explanation. I might be the wrong person to answer this - I haven't yet had a need for LVOOP in my projects - but I've been following all the discussions about LVOOP, and I've taken several classes in Java and used a bit of C++, and the implementation of objects in LabVIEW appears to be different enough (by-value versus by reference) that you'll probably be less confused if you jump right into OOP in LabVIEW rather than trying to learn it in C++ first.

[Mark Smith]

QUOTE (Cat @ Mar 19 2009, 05:27 AM)

I'm thinking about taking the NI OOP class. It appears I've missed the cruise, so I'll have to settle for a regular ole office building.

I stopped programming in C about the time C++ was getting popular, so I don't know much about object-oriented programming in general. Every time my cow-orker who is a C#.NET, etc whiz tries to explain it to me, it sounds like he's talking about ways of accessing typeDef-ed clusters with data and their associated info. It must be more complicated than that. I looked at the LV OOP stuff back when it came out in 8.2, but it seemed like it was adding code on top of what I was already doing. Once again, I assume my lack of knowledge is the problem.

My question is this: Do I need to learn C++ before I take the NI OOP course? I've read thru all the doc links I can find on this site and they've managed to underscore how little I know about the basic language of OOP. If they teach the class in that language (ie, here's how you all did it in C++ and now here's how we'll do it in LV) I'm sure I'll manage to stumble along, but won't get as much out of the course as I possibly could.

Any thoughts?

I don't think it makes much difference which language you use to learn OOP, but I would think C++ would be tougher than using a more strict OO language, mostly because you can write code in C++ all day and never have to use a OO paradigm. If you learn Java or C#, those languages force you into learning something about OO because there's just not any other practical way to do things. Mostly, it's about understanding the OO principles independent of the language you choose. I won't claim it's easy - it took me a long time to get my head around OOP and I learned it programming in C# before I ever started writing LVOOP. And I still have problems getting started on OOP projects - but in a sense that's a good thing because it makes one think carefully about the architecture before coding. If you don't design your LVOOP to take advantage of the inheritance hierarchy, then you miss one of the most powerful aspects of LVOOP and why I find OO programming in LabVIEW to now be worth the extra time and overhead.

But back to the question - I don't think it's C++ you need to know - it's OOP principles and the language used to describe them.

Mark

Edit: added links

http://zone.ni.com/devzone/cda/ph/p/id/7

http://java.sun.com/docs/books/tutorial/java/concepts/

[Justin Goeres]

QUOTE (Cat @ Mar 19 2009, 04:27 AM)

Every time my cow-orker who is a C#.NET, etc whiz tries to explain it to me, it sounds like he's talking about ways of accessing typeDef-ed clusters with data and their associated info. It must be more complicated than that. I looked at the LV OOP stuff back when it came out in 8.2, but it seemed like it was adding code on top of what I was already doing. Once again, I assume my lack of knowledge is the problem.

Yeah, that's actually a pretty good explanation. So you're already like 50% of the way there .

A key point (for me) is to remember that software is always an abstract representation of a system that you could (in principle) build in real life. And in real life, we interact with literal objects (like a scissors) that have literal properties (pointy, left-handed, jammed) and literal methods (cut). So it makes sense to impose rules on our software abstractions that sort of mimic the objects we deal with in real life, because it's easier for us to visualize them that way.

To carry my metaphor way too far, if you were "cutting paper" in software, there's nothing stopping the paper from somehow knowing that the scissors is left-handed. That's essentially because computers are magic. But it's probably dangerous to let the paper know that, because the paper really shouldn't know whether a left-handed or right-handed person is cutting it. Indeed, what if you later write "Scissors 2.0 -- ambidextrous!"? Now all your paper will be broken, because it makes assumptions about the scissors. All it has to know is "I am being cut." Just like in real life.

Again, there's nothing prima facie in the world of computers that prevents paper & scissors from knowing way more about each other than they really should. So smart humans have come up with programming paradigms that allow us to enforce restrictions on ourselves, to help us create better abstractions. OOP is the dominant way of doing that.

So there. That's encapsulation and information hiding. Now it's someone else's turn to explain inheritance .

And yes, at first OOP does feel like you're adding code on top of what you're already doing. In fact, it's possible that you're already doing good OOP-like things in your code to begin with. But using the native OOP takes some of the management work out of your code and puts it in the LabVIEW compiler.

[Grampa_of_Oliva_n_Eden]

QUOTE (Justin Goeres @ Mar 19 2009, 09:01 AM)

...

And yes, at first OOP does feel like you're adding code on top of what you're already doing. In fact, it's possible that you're already doing good OOP-like things in your code to begin with. But using the native OOP takes some of the management work out of your code and puts it in the LabVIEW compiler.

But the LVOOP tools really make that a lot easier being able to create accessors and methods that are almost "code Ready" without having to edit Icons, wire connectors etc.

"An Introduction to UML and Patterns" the author name escapes me was very helpful for me when I was first trying to get my head around OOP. The book uses a recursive method to design a "point of Sale" (cash register) application and progressivle gets more specific until the next thing I knew, I was putting aside the book, drawing up System Sequence Diagrams, documenting contracts and creating LVOOP classes. I admit that waht I did may not get me a good grade in a college OOP course but the app did what the customer wanted and it sold me on LVOOP.

Just trying to help,

Ben

[Tom Bress]

The book is by Craig Larman. I recommend it too, I'm reading it right now. The nice thing about the book is that he teaches UML and OO design principles hand-in-hand. He uses UML to model the conceptual system (domain model) and the OO software approach (design model). The UML visual serves as the "code", he very rarely shows what the code would actually look like in Java. So you can apply the principles directly to LabVIEW without a text-based language getting in the way.

By the way, I love cow-orker. Every time I read "coworker", that's how I pronounce it in my head.

QUOTE (neBulus @ Mar 19 2009, 10:11 AM)

But the LVOOP tools really make that a lot easier being able to create accessors and methods that are almost "code Ready" without having to edit Icons, wire connectors etc.

"An Introduction to UML and Patterns" the author name escapes me was very helpful for me when I was first trying to get my head around OOP. The book uses a recursive method to design a "point of Sale" (cash register) application and progressivle gets more specific until the next thing I knew, I was putting aside the book, drawing up System Sequence Diagrams, documenting contracts and creating LVOOP classes. I admit that waht I did may not get me a good grade in a college OOP course but the app did what the customer wanted and it sold me on LVOOP.

Just trying to help,

Ben

[jdunham]

QUOTE (Cat @ Mar 19 2009, 04:27 AM)

Any thoughts?

If you've ever put data in a variant or flattened string, and then accompanied that with an enum to tell the downstream code what kind of data is in the variant, then LVOOP makes that all much easier and cleaner.

[Mark Yedinak]

Another excellent book is the OO design pattern "bible" (Design Patterns: Elements of Reusable Object-Oriented Software) by the gang of four. This book is very good a presenting reusable design patterns for building OO systems. With respect to your question about learning C++ I don't believe that you need to learn a text based OO language but it helps to understand them somewhat. This is mainly because must books on the subject will present example implementations in one of the traditional text based languages so understanding them in a general sense helps when reading the books on the topic.

[shoneill]

I did actually learn (more accurately, I was taught) OOP in C++, but only many years later did the penny drop on the one issue I had serious trouble understanding. Inheritance.

As soon as I realised that Inheritance was something dealt with at compile-time, it all became clear. This happened when dabbling with LVOOP. All those years I could never get my head around OOP simply because I never noticed (or my books never actually said) that Inheritance was basically static when compiling. I was never able to understand how run-time inheritance changes could possible be handled sanely and this really put me off OOP because I had the feeling I just wasn't "getting it".

LVOOP is for me the perfect somution for "same same but different" type of code. I realise that won't make sense until you're actually understood LVOOP, but for me that pretty much sums it up. Common framework, uncommon internals.

Shane.

[Grampa_of_Oliva_n_Eden]

QUOTE (shoneill @ Mar 19 2009, 04:15 PM)

I did actually learn (more accurately, I was taught) OOP in C++, but only many years later did the penny drop on the one issue I had serious trouble understanding. Inheritance.

As soon as I realised that Inheritance was something dealt with at compile-time, it all became clear. This happened when dabbling with LVOOP. All those years I could never get my head around OOP simply because I never noticed (or my books never actually said) that Inheritance was basically static when compiling. I was never able to understand how run-time inheritance changes could possible be handled sanely and this really put me off OOP because I had the feeling I just wasn't "getting it".

LVOOP is for me the perfect somution for "same same but different" type of code. I realise that won't make sense until you're actually understood LVOOP, but for me that pretty much sums it up. Common framework, uncommon internals.

Shane.

There is a close relationship between inheritance and dynamic dispatching So I don't know where one end and the other begins.

In LVOOP dynamic dispatching is handeld at run time. That was the big plus for me because I needed to beable to add classes to an pre-existing exe. I just had to add the libray for the class to the right folder and the app found the new classes.

Granted I had to configure the new classes such that they knew what their inheritance was and that was done in the Project, but is was done after the exe was built.

SO the children have to know about their ancestors but the reverse in not required.

Ben

[shoneill]

QUOTE (neBulus @ Mar 19 2009, 09:37 PM)

There is a close relationship between inheritance and dynamic dispatching So I don't know where one end and the other begins.

In LVOOP dynamic dispatching is handeld at run time. That was the big plus for me because I needed to beable to add classes to an pre-existing exe. I just had to add the libray for the class to the right folder and the app found the new classes.

Granted I had to configure the new classes such that they knew what their inheritance was and that was done in the Project, but is was done after the exe was built.

SO the children have to know about their ancestors but the reverse in not required.

Ben

Thread is getting a little off-topic....

Dynamic dispatching (to the best of my knowledge) is determined at compile-time. An object with a parent class "polygon" will always cast up to "polygon" when used. It will have the methods from "polygon" available when used. It cannot be instantiated with something other than "polygon" as parent.

It reminds me of a passage from "kung-Fu Panda" (funny place to get an OOP quote I'll admit)

QUOTE

Shifu

: But there are things we *can* control: I can control when the fruit will fall, I can control where to plant the seed: that is no illusion, Master!

Oogway

: Ah, yes. But no matter what you do, that seed will grow to be a peach tree. You may wish for an apple or an orange, but you will get a peach.

Although dynamic dispatching is determined at compile-time, the usage of it appears to allow run-time associations. Instead, it allows run-time determination of which compile-time relations are to be called (if that makes sense). The dynamic dispatching "table" so to speak is determined at compile-time unless I've misunderstood something. So it may be "handled" at run-time, but it can never exceed the scope laid down at compile-time (unless there's a bug somewhere of course).

The fact that we can use a plug-in architecture like this (A great benefit of LVOOP IMO) is based on the fact that the inheritance (and the associated dynamic dispatching) for a specific class is pre-determined. If you take the same class, remove the inheritance and then try to load it as a plug-in, it will fail (right?). Given that the methods and name of the parents match, we have an addition to the dynamic dispatch table (I don't even know if there is such a thing, but I think that was to help visualise what's going on) is simply expanded. The content of the expanded part is again pre-determined from our compile-time associations. The SIZE of the dynamic dispatch table however can be changed at run-time.

An interesting question is: what happens if I use a class which inherits from a different version of my parent class? What if there's a method VI more or less in the new Parent class, will the plug-in architecture still work? Is there ANY flexibility in the run-time dynamic dispatch (or inheritance) linking?

I don't know if my post makes any sense whatsoever to anybody except myself.....

Please note that I may have all this back-to-front and inside-out and maybe even upside-down.....

Shane

[Aristos Queue]

QUOTE (shoneill @ Mar 19 2009, 04:59 PM)

An interesting question is: what happens if I use a class which inherits from a different version of my parent class? What if there's a method VI more or less in the new Parent class, will the plug-in architecture still work? Is there ANY flexibility in the run-time dynamic dispatch (or inheritance) linking?

Yes.

The child class does not record whether the VI is an override of the parent or not. It doesn't care. So if the parent adds or removes an implementation, callers of the child class don't care.

[Michael Aivaliotis]

I took an object oriented analysis class many years ago (before lvoop was released) and after I finished it I got a much better understanding of OOP. There is no coding at the analysis stage. I actually had a lot of fun. Honestly, I don't know how anyone can program OOP without a better understanding of analysis. Just my 2 cents. :2cents:

[shoneill]

QUOTE (Aristos Queue @ Mar 20 2009, 04:00 AM)

Yes.

The child class does not record whether the VI is an override of the parent or not. It doesn't care. So if the parent adds or removes an implementation, callers of the child class don't care.

Assuming the child itself doesn't call one of the removed parent VIs I presume.

Shane.

[Yair]

QUOTE (shoneill @ Mar 20 2009, 12:59 AM)

the dynamic dispatch table (I don't even know if there is such a thing

It's called a http://en.wikipedia.org/wiki/Virtual_table' rel='nofollow' target="_blank">vtable and if memory serves Stephen did refer to LabVIEW using this method, although a quick search didn't reveal anything.

[SULLutions]

QUOTE (Cat @ Mar 19 2009, 08:27 AM)

...I don't know much about object-oriented programming in general...I've read thru all the doc links I can find on this site and they've managed to underscore how little I know about the basic language of OOP.

Cat,

Looks like things have wandered far from your original question. I can't answer the part about how the NI course is taught, but I have (long ago) had a formal course in Object Oriented Programming in C++ and I also own Conway and Watts "A Software Engineering Approach to LabVIEW". I found the book to be much more helpful in easing me into the OOP world. It doesn't get you all the way there, but it does show you why you should explore OOP and teaches you how small modifications to your current coding practices can give you many of the advantages of OOP.

[shoneill]

QUOTE (Yair @ Mar 20 2009, 11:19 AM)

It's called a http://en.wikipedia.org/wiki/Virtual_table' rel='nofollow' target="_blank">vtable and if memory serves Stephen did refer to LabVIEW using this method, although a quick search didn't reveal anything.

Thanks. I wasn't so far off so....

Another small part of the puzzle filled in. That's the difference between a "proper" software developer and a wannabee like me.

Shane.

[Aristos Queue]

QUOTE (shoneill @ Mar 20 2009, 02:25 AM)

Assuming the child itself doesn't call one of the removed parent VIs I presume.

Naturally. :-)

[bsvingen]

Purchased both p-p-p-pattern books at the local university book store They better be good.

[Cat]

QUOTE (SULLutions @ Mar 20 2009, 06:23 AM)

Looks like things have wandered far from your original question. I can't answer the part about how the NI course is taught, but I have (long ago) had a formal course in Object Oriented Programming in C++ and I also own Conway and Watts "A Software Engineering Approach to LabVIEW". I found the book to be much more helpful in easing me into the OOP world. It doesn't get you all the way there, but it does show you why you should explore OOP and teaches you how small modifications to your current coding practices can give you many of the advantages of OOP.

The book sounded familiar. It just so happens I have it on my bookshelf (I pulled it out and noticed one of my cow-orkers had put a sticky note under the title with "A Graphical Comedy!" written on it. No respect... ). I'll take another look at it. Thanks!

[jzoller]

QUOTE (Mark Yedinak @ Mar 19 2009, 10:11 AM)

Another excellent book is the OO design pattern "bible" (http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612' rel='nofollow' target="_blank">Design Patterns: Elements of Reusable Object-Oriented Software) by the gang of four. This book is very good a presenting reusable design patterns for building OO systems. With respect to your question about learning C++ I don't believe that you need to learn a text based OO language but it helps to understand them somewhat. This is mainly because must books on the subject will present example implementations in one of the traditional text based languages so understanding them in a general sense helps when reading the books on the topic.

...okay, I must confess, I loathe this book.

The *ideas* in it are wonderful. The recognition that problems solutions can be broken down into a few narrow categories is absolutely revolutionary. But, I've seen too many "purist" implementations (some of them my own) based on patterns, that end up being 2% functional, and 98% pattern fulfillment.

The usual argument is that these are just poor pattern choices, but I've seen so many bad implementations (usually in Java) that I believe there is something fundamentally wrong with the idea of "code to pattern".

I'd recommend the book for the ideas, but I would keep it away from my code.

Sorry for the aside,

Joe Z.

[Michael Aivaliotis]

QUOTE (SULLutions @ Mar 20 2009, 03:23 AM)

...and I also own Conway and Watts "A Software Engineering Approach to LabVIEW". I found the book to be much more helpful in easing me into the OOP world. It doesn't get you all the way there, but it does show you why you should explore OOP and teaches you how small modifications to your current coding practices can give you many of the advantages of OOP.

I also unfortunately own this book. The words "Software Engineering" threw me off. The main useful sections are the ones describing how to create and use functional globals. There is an introduction to OO concepts but it's very weak. If you're a total novice then this book will help a bit, but don't count on it changing your life. The book had a very short lifespan when it was first released. It was relavent at the time but is way out of date and boring now.

Is there an LVOOP book out? Is anyone writing one? I'd buy that!

[bsvingen]

Having both "Applying UML and Patterns" by Larman and "Design Patterns" by Gamma et al or the GoF, it seems to me that Larmans book is really what I want. I have only browsed through them, but Larmans book goes into detail of the process of OO analysis and design, while the GoF assume that you already know all that and is more of a reference to typical patterns that have shown to be workin well.

[Yair]

QUOTE (shoneill @ Mar 20 2009, 01:32 PM)

That's the difference between a "proper" software developer and a wannabee like me.

Technically, I'm not a proper software developer (and definitely not engineer, since I don't have a degree). At most I can be considered someone with open ears, an adaquate disposition and a reasonably good memory for certain things. I think you also qualify for that category.