References from ActorCore.vi FP and Inheritance

[Jenso]

Ah ok, if I understand correctly this would look up the path of ActorCore.vi, then open the VI Ref and save that one. That is a good idea. The only problem that will then persist is, that this method cannot be used e.g. for Frontpanel indicators.

I could then get all controls of that VI and search for the label name but I fear that this might have a too high impact on performance. Unfortunately this software will be used to control our factory machines and thus timing is a crucial issue.

Thanks for the idea!

[Jonzarwal]

Hi,

You should have a look to my solution. The code to catch the FP reference is wrapped in the base class. Any descendant of any level can use it, as it focuses the right instance of actor core.vi. And as it is wrapped, there is no additionnal code required for your children actors.
I used this trick (inspired from some VIs from OpenG) to develop our UIActor, which is available here:
https://github.com/Step-AT/UIA_Framework
The VI corresponding to your need is UI_Actor/priv_Store.UI.Ref.vi, which is called by message before the actor core.vi. It works perfectly with any child of UI Actor , and grandchild and so on.

[Dhakkan]

---

@Jenso wrote:

---

---

I would discourage this. Multi-level class (not interface) inheritance has proven to be a headache for OOP practitioners across OOP-capable languages in the context of feature enhancements and code maintenance.

---

Ok so that is bad to hear. I thought that I could now make a leap to lightspeed with developing an AF OOP Framework 😀. Can you give me one or two examples for these problems? I only remember this to be a problem in languages where you can inherit from multiple parents.

---

I may have gone overboard in discouraging multi-level inheritance without fully understanding your environment. On a flip side, such inheritance schemes have indeed worked successfully where the team is in sync and has tight control of product design and implementation. If yours is one such, certainly feel free to implement your design.

As for problems, I understand there to be generally two kinds.

One problem is usually observed in code bases where the main application business logic works with abstract classes. The violation relates to Liskov Substitution Principle (LSP). Jon McBee has a nice narrative on this. In a nutshell, the concrete implementations must be fully compatible with the intent of their abstract (or base) class. When a code implementation misses this, LSP violation has occurred.

Another class of problems occurs in designs where application business logic usually works with concrete classes directly. In such designs, the base class(es) provide the foundational implementation for their subclasses. The subclasses provide supplemental capabilities, according to their purpose. Just as in physical building foundations, the robustness of these ancestor classes matter. If these foundations are frequently messed with, they could lead to a brittle structure. (Hence my previous reference to headache for feature enhancements and maintenance.)

---

@Jenso wrote:

---

---

How could an approach to composition then look like? I do not have a multi-parent inheritance (multiple inheritance is only allowed for interfaces as far as I know). So in my thinkings I would approach that by creating let's say libraries for specialized tasks.

In the example above when I have a testpanel view (e.g. one for each resolution) then I would use a testpanel library containing the most important methods and then use those in each view? 

---

I wonder if MGI Panel Manager or equivalent may be of use to you. I haven't had the need to use it yet, but do have it already installed via VIPM on my machine, just in case. 🙂

[Jenso]

Thanks for the honest reply. Actually our team is far away from "in sync". Our team is spread over various plants in the country and until now everybody is cooking his own soup. The mission objective that we then got was basically: "Wouldn't it be nice if you could all use the same software? Because you know its only software" (our bosses tongue 😄).

Now after we had a look at all the differences of our factories I had the idea to step 3 steps in direction of future (which is generally still laying in the past 😁).

So now we need to develop a new absolutely flexible framework. It consists of a PackedLib PluginStructure, Actors communicating via Interfaces, indiviual UI (realized via those views), Hardware abstraction and a lot of polymorphia and inheritances and so on.

Everybody of the team is eager to tackle the new challenges but I do have to admit, that some are not as fast as the others.

That is then basically my idea behind that multi-inheritance (which will not only be applied to the views). I wanted to "pre-create" as many modules as possible with simple APIs. That way I hope we will have a small team of "architects" and some "applicators".

I fear that the less levels of inheritances I have the more the developers have to understand of the frameworks on themselves and the more different solutions will arise.

But after reading your argumentation I honestly hope that this is not the totally wrong way.

I want to thank you anyway for your good advice!