shoneill

Regarding this statement: I seem to realise that people are referring to changes in the behaviour of the object exposing the interface under test (Execution time etc.) and not the interface itself. These (for my definition at least) are not changes to the interface. Hence my comments on the original post. It's a pedantic thing but for me changes to the interface (acceptable input range, fuinction definitions etc.) do not equal changes measurable via the interface. But hey, I have zero formal software training so my personal opinions are just that, personal opinions. A statement like: mif I change something in the private scope it ought to make a change which is measurable over the public interfcace if my tests are "well designed". sounds completely different to me. Shane.

Hey, if I'm wrong, I'm always willing to learn. The statement I referred to above just seemed not quite right, and I'm not sure at the moment of you guys agree with me or not.....

Indeed. I find it weird to expect a private implementation change to be reflected in the public interface and still claim to be encapsulated. Seems a contradiction to me. Saying that wou're going to test the private implementation (via whichever methods are most preferable for any given class) is something completely differen to saying "I'll test the private implementation via the public interface".

Only if your encapsulation is bad. I really don't know if I can agree with this statement at all. It seems very non-oop to me. Shane.

Yeah, that's been int he LV help for years but to the best of my knowledge it's either simply wrong or hugely misleading. I work a lot with events and with subpanels and I've never encountered a problem. I hesitated for a long time because of this text in the LV help. I never understood what it meant. Shane.

WHAT? I'm certain I attached something.... D'oh Here it is (maybe) Random class.zip

Well here's something to demonstrate (in true Quick and dirty mode - the delete button isn't coded for example) to show the idea I'm getting at. Shane.

This is all quite feasible with what I'm proposing. Each object in the array can be of a different run-time type (but all interpreted as a common ancestor in the IDE). When you have a new element, just insert into the array. If it's selected, get the object at that index and tell it to display it's editor window in the subpanel. Each object is then responsible for taking care of its own user interaction which aids encapsulation no end. There's no problem with having different kinds of children in a dynamic array at run-time thus mixing and matching test objects as you see fit. The only difference is that instead of calling a single UI, you extract the object at the required index and tell it to show it's UI. Once you've grasped that part (and implemented some working code), the rest is trivial really. Shane.

Amen to that. Well this is where I might be able to chime in. I am a firm believer in code generalisation and have often run into this "problem" of having a nice re-usable scnario which gets snagged on the nitty-gritty details fo the actual implementation. One such thing is the "How do I edit the data in my (possibly unknown) objects using a generic interface (Listbox)"?. My answer to this is that the object whould handle this itself. I'm sure I've made references before to ustilising self-displaying objects for exposing their editing capabilities (I think it was in response to a preferences dialog) and I think this is a great way to implement this problem as well. You can either go via text (using a table) and have the object tell you if the entered data is correct or you can have a sub-panel in your XControl into which the object to be edited places its own UI for editing. This way you can mix and match objects of different types and the editing becomes mush easier. You can expand beyond the originally-concieved functionality and the Listbox XContro becomes truly re-usable. Selecting a new object int he list unloads the ond object and loads the new one into the subpanel. Easy peasy. You can retrieve the new values by either utilising DVRs in the XControl (thus ensuring automatic synchronicity) or via events or via whatever method takes your fancy. You can also just take the return value from the UI when it exits (when the user says they're finished or when another item is selected and the current object is forced to unload). Easy peasy lemon squeezy. But that's just my opinion man. Shane Ps I specifically mean a link to THIS topic.

Version 1: Would a more suitable OOP approach not be to write some private class methods to pick the values out of the variant and write them to the original input class, thus not breaking the object wire between input and output? On error, values are not retained, no dynamic dispatch problems. I find the trust level that the right input object has the right filename to output exactly the right output object type a bit too high. Or perhaps version 2: Read in the object from file, try to convert it to the same as the input object (so that you have the input object AND the loaded object) but then transfer the data using private class functions (Accessors) instead of simply outputting this loaded class. This too prevents breakage in the dynamic dispatch wire path. In the case of an error, the input object is simply passed out as the output object, no dynamic dispatch problems. Shane.

What happens if the GXML throws an error? Shane.

The XML isn't taken from or passed back into the class, it is a different representation OF the class. i.e. it's a serialisation / deserialisation of the entire class which is being performed. I agree though that it should be OK, you just need tobe careful not to introduce nasty run-time bugs this way. It softens up the strict typing of classes just a little to let some nasty bugs in if you're not vigilant enough. Shane.

My understanding is that according to the wire flow LV cannot (to 100%) guarantee that the object type on the wire is EXACTLY the same (not a child, not a parent) as the input but you're basically telling the compiler "Chill bro, I've got it under control". If for any reason (sn error for example) the object you are changing the run-time type on IS different, you'll get a run-time error. The compiler should be telling you "Pfft, under control you say....". I may have paraphrased some typical compiler jargon.... Shane.

I've posted a simply example of self-displaying objects on the Dark side. I was actually trying something with DVRs but it shows the principle of self-displaying obejcts also. Link: http://forums.ni.com/t5/LabVIEW/LVOOP-DVR-with-non-blocking-Dynamically-dispatched-calls/td-p/2126824 Shane.

Well it depends on the usage intended but although it's no neccessarily trivial in itself, it solves a LOT of other encapsulation problems you might otherwise have. You can create new classes after compilation and have the neccessary UI already included since it's a private class method. Shane.

Why doesn't the XControl initialise itself. That way there's much less code on your VI Block diagram.

Why not use some self-displaying objects? Simply incorporate a dialog display routine into your class definition and you have XControl light which allows your objects to display themselves in a subpanel for editing (perfect for Preferences dialogs). The host program simply juggles Configuration objects and needs to know nothing of the actual configuration settings. Shane.

That's all fine and sounds like a pretty good way of going about things. No complaints here and nothing I have posted earlier even hints at this being a bad idea. The only point I was trying to make was that the term "decoupling" is inherently a grey-area thing. There are pieces of software which are obviously more or less decoupled from each other but it's not a universal scale where one can say I'm 90% decoupled...... Adding to this the fact that "full" decoupling isn't achievable in any real-world sense makes certain aspects of the discussion which were going on kind of silly (regarding whether the decoupling is complete or whatever). The act of decoupling (to whatever level is appropriate for a given task) is a good thing and I didn't mean to make any negative comments regarding the efforts to decouple. Whether you call it decoupling, cliient-server, distributed producer consumer or whatever is secondary to the fact that the foundation you're building your software on is solid. Shane.

But true decoupling in a software architecture sense is only achieved in this real-world example if your new boss knows you exist but does not know what you do or how or how much you earn. In a software world, 100% decoupling is not achievable without having two completely independent pieces of software. As soon as both rely on a common interface (messagine protocol) there is inherently a certain amount of coupling present. So in a real-world sense I think the discussion about "full" decoupling is a discussion without any merit unless it's purely rhetoric. Even sharing data structures introduces a certain level of coupling between two modules. As with server up-time, squeezing the last few fractions of a percent of perfection (decoupling vs up-time) requires exponentially more effort. 99% decoupled software costs a WHOLE lot more time and effort to program than a 90% decoupled software in the same manner as a 99% reliability of a server is in a different ball park to 90% reliability. When it comes to decoupling, there are ONLY grey areas. Just my take. Shane. PS Here's a cool qoute from Wikipedia on the subject: "No couplingModules do not communicate at all with one another."

Correct, my bad. Given that an API is essentially given, the class is set for the base class defining the API but it will accept child classes no problem. SO no DD, I had a speak malfunction. Shane

Your example VI has IMAQ functions in it so I can't run it here at work. Why don't you want to rotate it using IMAQ functions? Why do all the work yourself? Shane PS YOu can also simply set the coordinates for the IMAQ functions which allws you to specify areas of interest without even having to rotate the image.....

Personally I find the use of polymorphic VIs (The ones with drop-down list, not auto-selecting ones) with LVOOP because it gives a one-stop shop for the API, not neccessarily the underlying objects. Each element in the polamorohic VI can be a different accessor or method class which the user can use at will. The input class is obviously always dynamic dispatch, thus unifying the advantages of both. This is all pre-2010. I'm aware some of these functions are now supported in LV 2010 natively. Shane

Cheers Paul. I must order that book.

I was just thinking of a method to achieve something at work when I thought of an idea which almost certainly has a formal name in OOP. Since you guys are generally better at the formal side of things than me I thought I'd pop out a question. If I have an architecture where I have a multitude (>1) classes which could concievably be used to process a certain input data (format the same but contents different) I don't want to limit my expandability by hard-coding which class handles which data. If I then incorporate a method into the classes to tell me how well they can deal with the data and then choose the best fit, what would I call this approach? For example: I have a control reference. I have a class to handle digital controls and I have a class to handle Strings. If All I have as an input is "Control" I send this to a function of the objects of my different classes and they tell me if (and how well) they can handle the specific object being passed - taking care of their own up-casting and down-casting as required.) Shane

Why not simply decouple the UI part from the Instrument part using a notifier? Shane Ps This way the delay is determined by the instrument and is not hard-wired in the code (I have simulated different delays for different functions in this example). User Input Delay Example_Intaris.vi