Most suitable method to analyze data?

[wiebe@CARYA]

---

@Haddock01 wrote:

I have read the easieast totorial from the link you gave me and I understand how my first prototypes should look like.

---

Good. We can validate it if you like. Not that I want to question you, but it's hard to get it right the first time, and a bad start might spoil the fun.

If you want to 'document' (design) your prototype, it's worth learning UML when learning OO. Although it's almost impossible not to. At the OO basics, you only need the UML basics (a rectangle ). But you might as well try get it right from the start.

---

@Haddock01 wrote:

 Typedefs and polymorphism seems to be the key to OOP.  I will try to test some examples and build on them.

---

That makes sense form a C++ PoV. Classes are kinda like typedefs, and in C++ they are special structs. In LabVIEW, we (I) don't think of classes as typedefs, mostly because they are so much more then typedefs. EDIT: In NXG they are much more like typedefs, it's not 'wrong'...

Polymorphism is one of the pillars of OO, next to encapsulation and inheritance.

Once you make a class, you are already using and benefiting from encapsulation (one wire contains all the data, the class contains all the code).

More on Inheritance and Polymorphism later*

---

@Haddock01 wrote:

I remember from the big project. It consist of many VI:s that had name like "Fill tank", "Flush tank", "regulate tank" and so on. Every class had there own llb.

---

Classes are like libraries (.lvlibs, .llbs are obsolete (or should be considered obsolete, IMHO)). A class isn't a library, or at least a library isn't a class, but libraries and classes share lots of properties. And a class can be in a library.

---

@Haddock01 wrote:

Half was files that made things happen.

---

You're 1st library will be (initially) 100% files that make things happen.

---

@Haddock01 wrote:

The other half of vi:s had som code that was just junctions. I don't know what they did. Something with dataflow.

---

So once you made your class, let's call it "Measurement results" (always go for a noun). It will have methods like "Get From File", "Find ID" (always go for verbs). That is great. No matter what is added, the internals can change, but the users of your class won't.

Now you want to use this class. If\when you get the hang of it, you might consider putting other things in classes. That means, those classes will either contain "Measurement results", or use "Measurement results".

that means your class will be coupled with other classes. That's probably what you mean by 'junctions'.

---

@Haddock01 wrote:

Every vi had a blue-green thread that was coming from a source that was connection to that particular class. Typedef? 

---

No, objects, instantiations of the class. But in a C++ lingo, those objects\classes are typedefs.

You can change the colors of those wires.

*

Spoiler

Inheritance is lots of fun, but should be one of the next steps. For instance, you can make a "Results" parent, a "Measurement Results" child, and a "Simulated Results" child. Then if you want a solid test case, or when you don't have measurements, you can switch to "Simulated Results" for testing. Polymorphism allows you to switch between Measurement Results and Simulated Results, because they are "Results".