Decoupling the UI

[Daklu]

To return to a point I made awhile back, if you UI and core engine cannot be on separate computers on a network, then you are not decoupled.

I understand what you're saying and agree with you in principle. What I'm struggling with is the implied idea that there is an arbitrary line you can cross where your UI transitions from coupled to decoupled.

"Coupling" is a term we use to describe how much component A relies on component B to do something useful. Or to look at it another way, how extensively we can change component B without affecting component A. For any two components to work together to do something useful there has to be some degree of coupling. Even if the UI and core can each be on different computers they're still coupled. At the very least they have to agree on all the details of the communication interface--the network transport protocol, the set of accepted messages, the message format, etc. Taking a step back they also have to agree on who should implement the functionality required for each feature. Take loading a file as an example. The UI passes a path to the core of a file that needs to be loaded. Who is responsible for making sure the file exists and is in the correct format? (The answer isn't important. The point is they have to have reached an agreement.) Looking at the responsiblities a little more abstractly we could even say the core is coupled to the UI because it needs the UI to tell it what the user wants. Sure the core can execute without the UI, but can it do anything useful for the user?

I think what you're describing is better characterized as source code dependency. Injecting UI references into core code definitely makes the core dependent on the UI's source code and creates a relatively high degree of coupling. Breaking source code dependencies is a huge step towards reducing the coupling, but strictly speaking, the only completely decoupled components are those that don't interact at all... anywhere... ever.

[John Lokanis]

Daklu - fair enough. I can agree with that.

I am trying to architect some code where the UI will be as dumb as possible but still as decoupled as possible. In other words, with you example, the UI will send the file path to the core but the core will do all the error checking on it and send back any error messages to the UI to display. The UI code will only deal with the controls on the FP and other things that need to be displayed.

My goal is to eventually move the UI off the computer that the core code is running on, possibly replacing it with a web interface. Also possibly replacing it with a multi client, single server paradigm.

[GregSands]

I understand what you're saying and agree with you in principle. What I'm struggling with is the implied idea that there is an arbitrary line you can cross where your UI transitions from coupled to decoupled.

I disagree. If the core can operate independently of the UI, then it is decoupled; if not, then it is coupled, although there is certainly a wide range of the degree of coupling. But passing a reference from the UI to the core implies that there is a particular control (say a graph) which the core can interact with. It may be easier to think about a "decoupled core" which is able to run independent of whatever UI is used - or not, it could also work exactly the same in a "batch mode" without any user interface at all.

What I would agree with is that for most situations, writing a fully decoupled UI/core is not necessary or even practical. It certainly may be slower, and require several copies of the same data. But for those cases where it is warranted, I don't think it is particularly difficult. It's a matter of defining a "data interface", and when using a dataflow language, that almost writes itself.

[Mark Yedinak]

Coming in late to the discussion I have to side with John. While JG's approach is clean, it is not decoupled. Simply look at your classes in the processing tasks. They are called UI methods. In a truly decoupled system the processing tasks should have absolutely no concept of a UI. It manipulates data, controls devices, reads data, etc. All of the processing tasks should be able to be added to an application that has absolutely no UI at all and is machine driven. As John mentioned the purest form would use raw TCP or some defined standard (TCP based most likely) that simply passes messages. In this manner the UI is free to change how the data is represented, stored or thrown away. Even using JG's suggestion about overloading the class with the specific implementation implies the lower level processing tasks are modified. It may occur in the form of a plugin but it's internals need to be changed. In john's approach you would never have to touch the processing code unless you wanted extend what messages your were passing. However even this API should be general and flexible enough to allow this type of change with minimal effort.

[jgcode]

Seems like some people are going around in circles.

Mark, you use the term "truely decoupled" which implies that there are different levels that describe decoupling. Of course what John is saying is the higher level of decoupling. I have not disagred with that.

What also has been said is that applications can benefit from a level decoupling depending on requirements. I simply presented 'an example'.

Therefore, comparing the two directly does not make sense.

[Daklu]

I disagree.

Woo hoo!

If the core can operate independently of the UI, then it is decoupled;

Hmm.... so define "operate independently" for me. (I'm not being pedantic, honest. These are the thoughts running through my head as I wonder exactly what you mean.)

Does that mean you can build the core into an executable and it will execute without any errors, even with the UI layer removed? Is the lack of errors a good enough qualifier, or does it actually have to be useful? (i.e. Does it have be able to *do* some of the things that would normally be accomplished via UI interaction? Say... via the command line and batch files.) If useful functionality without a UI is a requirement, how much of the UI's usefulness has to be replicated at the command line? 50%? Why not 49%, or 51%? Any arbitrary cut off between 0% and 100% puts us in the purely subjective realm of figuring out exactly what should be considered "useful" and how useful it is relative to everything else. Since you're proposing a concrete standard, subjectivism isn't allowed. So we have to choose... Using the 0% bar reduces "decoupled" to mean the same thing as "no run-time dependency." Using the 100% bar makes "decoupling" an impossibility--no command line interface can offer all the same things as an event-driven gui.

< Thinking out loud >

Seems to me that in addition to different degrees of coupling, there are different kinds of coupling and its meaning is very context-dependent. Maybe I have co-worker who asks me if I've written any code to find prime numbers. "Sure, give me a couple hours to decouple it from my source and I'll send it to you." Clearly I'm referring to source code dependencies. Could that bit of code "operate independently?" Maybe... I probably could compile it into an executable but it's going to need more code before it will do anything useful. There's also run-time coupling. If component A (the core) and component B (the UI) collaborate at run-time to accomplish some task, they rely on each other to do certain things. Perhaps A could have collaborated with C (the command line prompt) instead of B. I don't think that matters. At that point in time A and B are collaborating--and coupled--while accomplishing that task.

I can't see how "decoupled" can be anything but a relative and subjective term that, like "warm," resists a black and white definition. When is something decoupled? Here's my definition...

Decoupled - A chunk of executable or source code separated enough from everything else so I can do what I want to do without requiring more effort than I want to put into it.

I am trying to architect some code where the UI will be as dumb as possible but still as decoupled as possible.

When I create really thin UIs there ends up being a lot more messaging between the components as I try to keep the data on screen and the data in the core synchronized. That's not necessarily a bad thing but it does take longer to implement and can be harder to follow the execution path. I'm still trying to find the right balance. In my last project I recently switched from a thin UI to a slightly thicker UI. The UI code, not the core code, manages all on-screen data (test config, sequences, etc,) including loading and saving the files.** That data is passed to the core as parameters of the StartTest message. The result is much simpler; I was able to eliminate at least 2/3 of the messages between the two components. There's always tradeoffs and almost never a clear-cut answer. That's part of the fun, yeah?

(**I have a class for each of the files that does that actual loading and saving, so it's not directly managed by the UI. The UI just retains those objects until the test is started.)

[John Lokanis]

Think of the UI as your boss and you as the core. Your boss tells you what to do but can't doing anything himself. You have to do all the work.

Therefore, you are decoupled from your boss. He can be fired and a new boss brought in and you will still do the same work. If you are fired, the boss can't get anything done without you! (one of the joys of being a LV dev )

[Grampa_of_Oliva_n_Eden]

Think of the UI as your boss and you as the core. Your boss tells you what to do but can't doing anything himself. You have to do all the work.

Therefore, you are decoupled from your boss. He can be fired and a new boss brought in and you will still do the same work. If you are fired, the boss can't get anything done without you! (one of the joys of being a LV dev )

In this above exchanges above a point that has not been made is

"What is the app supposed to do?"

If the app has no no UI requirements, then it seems complete decoupling is possible. He#$, I wrote one of those 12 years ago before I knew what OOP was. THe GUI only had a bitmap of the folw originally imagined by the customer and nothing else. But then again if a an app does not have a GUI is discusions of decoupling form the GUI becomes a high-tech version of "If a (an) tree (app) falls in the forest (lacks a GUI) will it make a sound (can it be decoupled)?"

So continuing on my philosophical trek...

Interacting with widgets and devices

When I write code to interact with GPIB widgets or DAQ devices, I do not start by switching to kernal mode but rather reply on the methods and properties offered by VISA and DAQmx. The Classes that use those services, are coupled to those services and depnd on them to work and will break if they go away. Provided the app has to interact wiht real devices (simiulation not concidered) the code will also depend on the functions/commands (services) offered by the widget and it will suffer if the used functions go away. Now to apply what I think Feilix was saying... VISA is an abstraction layer that reduces the coupling between code and widget.

LV offers a set of virtual objects that allow us to interact with users. If our apps have no UI requirements, then the virtual objects services are not required and decoupling (disclaimer: implementing a global abort in batch type apps, I have not pondered in this context).

Three ways to implement a GUI?

I'm just musing out-loud so maybe more.

Traditional

Prior to LV 6i we did not have property nodes and control references but rather we had attribute nodes. We had two choices, use the native LV controls "as-is' and avoid attribute nodes, or "over-ride" the native operation and use attribute nodes to do what was required byt the app. Still attempting the work on my vocabulary... the GUI and the code were tightly coupled. You had to ""ctr-A Ctl-C" to duplicate the apps GUI functionality. Complex LV apps that date back to LV 5.1 or before had very complicated diagrams. THere is an example of of a "bad diagram" over on the Dark-Side that I am convinced was developed in LV 5.1 and upgraded.

Cotrol References:

With LV 6i we picked-up the ability to move the code that did complex manipulations to over-ride the native behaviour of LV's widgets into sub-VIs. This provided a level of abstraction we did not have previously. We could now write sub-VIs that performed a common function by acted on different objects. They let us implement a layer of abstraction between a class of of widget on the GUI and code that used that widget.

Concrete primitive example - Back in 6i, it was still common to poll a cluster of booleans for a command or a mode change. I wrote a re-usable AE that would accept the control ref and return the name of the first boolean true. It could be used on any cluster of booleans blah, blah, blah, It added a layer of abstraction to a a widget of type "cluster of boolean" and de-coupled the code that used it from the actual instance on the GUI. To use this primative abstraction level, the code that used it had to have some knowlege of what object it had to work on (the cluster the user clicked on was tightly coupled to the opeation of the application) "Expert Pattern" (?). In this case the code that used the abstraction layer (AE) "pushed" the control ref to the AE.

"With great power comes great responcibility." (I don't know the author) But control references, even in these early days could be dangegerous if property >>> value is used to store data rather than a way to query or update a user. I feel this would be tight coupling and can become quite restrcting.

Time goes on... we learn more about control references navigating same and some more complex applications of control refs.

Dynamic event Structures - another double edged sword that helps to couple or decouple. I tend to think that dynamic eevnt structure as a powerful decoupling technique. Going back tot those Old apps... If an app was not in "Supervisor mode" we could not respond to a button so the "Non-Suppevisor mode" had to "Not_DO_Something". So turning on and off events feels like I don't have to worry about the stuff I'm not supposed to do since it just does not happen (the event is not registered and just does not fire) so CODE RUNNING IN event stuctures become less coupled to the GUI since events only fire when appropritate. "Code running in" events only run when they have to run adn when they run they do what they are supposed to do (e.g. The "load Design" button does the same thing when one button is pressed in design mode and another button pressed in operate mode). "The other edge" that come with Dynamic events enters when we concider when to register/unregister what, when. The app has to answer those questions and "someone" is responsible for knowing how to find those answers and is therefore tightly coupled to the GUI to implement the non native LV functionality (control don't hide show themsleves, yeeessshhh!). "Somebody" has to do it. This part of the code is coupled to the GUI is coupled to the GUI in the fact that the widgets it hides/shows registers/unregisters have to be available. They don't necessarily have to be a particular widget on a particular GUI. Provided there are are compatable widget SOMEWHERE, it could still work.

Example: My lame example above. I could have nested modes of operation tht the operator moves through using a series of clustered booleans. As the modes change the cluster get hidden shown based on the button presses. The same sub-VI could execute on all modes to figure out which button wa clicked and different event cases would caall that sub-VI depending on event registrations.

But if another customer wanted to use the same application but wanted to implement it not doing the hide/show thing but rather present pop-ups wiht the clusters, the code runs the same but operates on different yet compatable widgets (I admit I would avoid adding this level of complexity unless the app required it).

Another Tightly coupled applicaiton of events is the use of "Event Signalling". THis seems like a tightly coupled situation but I have not thought about that twist yet.

So because my wife tells me the pot roast is ready I'lll wrap it up now...

The coupling between code that has a GUI and the object offered by LV is similar to the coupling between apps and the widget they control or monitor. We can have apps that are completely decoupled from the GUI if it has no GUI requirements.

As long as there are "special requirements" there will be coupleing.

XControl are probable an example of decoupling.

Take care,

Ben

[GregSands]

Hmm.... so define "operate independently" for me. (I'm not being pedantic, honest. These are the thoughts running through my head as I wonder exactly what you mean.)

Does that mean you can build the core into an executable and it will execute without any errors, even with the UI layer removed? Is the lack of errors a good enough qualifier, or does it actually have to be useful? (i.e. Does it have be able to *do* some of the things that would normally be accomplished via UI interaction? Say... via the command line and batch files.) If useful functionality without a UI is a requirement, how much of the UI's usefulness has to be replicated at the command line? 50%? Why not 49%, or 51%? Any arbitrary cut off between 0% and 100% puts us in the purely subjective realm of figuring out exactly what should be considered "useful" and how useful it is relative to everything else. Since you're proposing a concrete standard, subjectivism isn't allowed. So we have to choose... Using the 0% bar reduces "decoupled" to mean the same thing as "no run-time dependency." Using the 100% bar makes "decoupling" an impossibility--no command line interface can offer all the same things as an event-driven gui.

What I mean by "operate independently" is that the core doesn't do UI. It communicates through a clearly defined I/O interface - e.g. takes in commands+data, and returns data+status. Absolutely, it has to be useful. But the issue of what UI functionality is "replicated at the command line" doesn't have anything to do with the core. Like I said, it's easier to think of a decoupled core than a decoupled UI.

Simplest example I can come up with on the spot - the core accepts two commands: "Compute" and "Exit"; and one datatype: "1D array of DBLs". It returns a result (which is also a 1D DBL array), and an I32 Error Code. Perhaps the whole thing is set up using queues, but it could be through disk files or a serial port - as long as it's defined, it doesn't matter. Now the core doesn't care how the result is used - whether printed to a text screen, displayed in an array control, graphed, or saved straight to disk. It doesn't interact with the user on how to deal with an error. It is 100% decoupled.

For some things, this approach is useful; for many it is not. But I think it would be generally true (and as true of my own code as anyone's) that computational parts of my code have way too much dependence on the particular UI that is used. Usually this comes about because things are written "to work now", so as long as the UI doesn't change, it doesn't matter. But if I decide I need to replace a Waveform graph with a 3D graph, then all these references which are directly manipulated now need to be completely reworked.

Edited February 27, 2011 by GregSands

[shoneill]

Think of the UI as your boss and you as the core. Your boss tells you what to do but can't doing anything himself. You have to do all the work.

Therefore, you are decoupled from your boss. He can be fired and a new boss brought in and you will still do the same work. If you are fired, the boss can't get anything done without you! (one of the joys of being a LV dev )

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."

Edited March 27, 2011 by shoneill

[Daklu]

In a software world, 100% decoupling is not achievable without having two completely independent pieces of software.

So in a real-world sense I think the discussion about "full" decoupling is a discussion without any merit unless it's purely rhetoric.

When it comes to decoupling, there are ONLY grey areas.

Amen. You've greatly simplified what I was trying to say. (Wish I had a full-time copy editor to review my posts before I submit them...)

Extending that thought a bit, since "decoupled" has no concrete, objective definition it follows that any assertions that a particular component is "coupled" or "decoupled" are based on an arbitrary set of requirements. Unless those requirements are identified and agreed upon it's unlikely a group of people will reach a concensus.

[bsvingen]

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."

We are developing on RT targets using cRIO and other embedded computers. The UI runs on a touch screen panel computer. This is decoupling in the correct sense IMO. The UI and logics run on different computers (kilometers apart), with different OS'es, in fact three OSes. The same architecture could also be used on one single computer with virtually no change in the code. The main point is that the UI is the "plug-in element", not the other way around. This is straight forward RT development using standard architecture learned at any RT course by NI.

[shoneill]

We are developing on RT targets using cRIO and other embedded computers. The UI runs on a touch screen panel computer. This is decoupling in the correct sense IMO. The UI and logics run on different computers (kilometers apart), with different OS'es, in fact three OSes. The same architecture could also be used on one single computer with virtually no change in the code. The main point is that the UI is the "plug-in element", not the other way around. This is straight forward RT development using standard architecture learned at any RT course by NI.

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.

[bsvingen]

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.

If the UI and the "logics" can run separately, they are decoupled IMO. But decoupled does not mean void of interface, obviously there has to be some interface and some communication of data or there would be two completely separate programs (of course also decoupled, but irrelevant). A close coupled program has no real interface since the UI and the "logics" are woven together, as in a typical PC LV application. So decoupled means separate programs communicating through an interface. The two programs only have to know the interface.

[Grampa_of_Oliva_n_Eden]

Amen. You've greatly simplified what I was trying to say. (Wish I had a full-time copy editor to review my posts before I submit them...)

Extending that thought a bit, since "decoupled" has no concrete, objective definition it follows that any assertions that a particular component is "coupled" or "decoupled" are based on an arbitrary set of requirements. Unless those requirements are identified and agreed upon it's unlikely a group of people will reach a concensus.

Soooo.....

This entire thread has no possilbe conclusion and is just an example of being hearded by a Cat?

Ben

[Daklu]

This entire thread has no possilbe conclusion and is just an example of being hearded by a Cat?

Herded? I think it's more like dropping a dead deer in a pack of hungry wolves.

Sure we can make conclusions from this thread. I already have:

1. We can't agree on the criteria of "decoupled." (And I haven't seen any compelling arguments for accepting one set of arbitrary criteria over any other arbitrary set of criteria.)

2. Without a strict set of criteria, "decoupled" is meaningless in and of itself. It only means something when considered against a set of expected changes.

3. Since we obviously mean something when we use the word "decoupled," we each apply our own set of expected changes to the code in question and come up with different answers, all of which are correct.

Conclusion #1:

Therefore, when someone asks "is x decoupled?" the only good response is, "what changes do you expect to make?"

Conclusion #2:

Cat is a rabble rouser.

[John Lokanis]

If the UI and the "logics" can run separately, they are decoupled IMO. But decoupled does not mean void of interface, obviously there has to be some interface and some communication of data or there would be two completely separate programs (of course also decoupled, but irrelevant). A close coupled program has no real interface since the UI and the "logics" are woven together, as in a typical PC LV application. So decoupled means separate programs communicating through an interface. The two programs only have to know the interface.

I think this sums it up for me. Especially the bit about a defined interface. That is what I was going for. I would only add that the interface should be able to cross any boundary (interprocess, inter-application, internal network or internet) as dictated by the needs of the user.

[Grampa_of_Oliva_n_Eden]

I think this sums it up for me. Especially the bit about a defined interface. That is what I was going for. I would only add that the interface should be able to cross any boundary (interprocess, inter-application, internal network or internet) as dictated by the needs of the user.

So what about those applications that require more throughput to the GUI than can be maintained using your favorite flavor of network interface?

I often have to smooth out the data path to the GUI from the data source in order to keep up with the data. Including overhaed to realize the connection without direct connects would impact performance to the point where the hardware could not keep up. So if all "good" designs have a decoupled UI and a decoupled UI has to have cross platform cpabilities, then I suppose I will have to settle for specializing in developing bad code.

I will not add that to my brag-list but it does keep the family fed.

And if we run with that twisted idea, then sometime in the future we should expect both the CPUs and the networks to improve their perfromance, in which case those cross platform apps would be possible. So then we have code that was previous perfect but unaccepatble change into perfect and aceptable... Which really screws with my head since what is good vs bad should not change with time, but that is probably the old-foggy in me speaking.

Ben

[John Lokanis]

So if all "good" designs have a decoupled UI and a decoupled UI has to have cross platform capabilities, then I suppose I will have to settle for specializing in developing bad code.

I don't know where you are going with this good vs bad thing. Decoupled code is not necessarily good and strongly coupled code is not necessarily bad. No one is trying to make those kind of judgments here. What we are trying to do is define what coupling is and what the benefits and pitfalls are.

Most of the discussion has been surrounding what decoupling means. In that area, there has been some disagreement but I think we have come to a reasonable conclusion.

For me, this has been helpful because I can now look at my designs and ask myself: "will decoupling offer any benefits to this project?" and "what steps will I need to take to decouple the UI from the rest of the code".

Right now I have a strongly coupled design that I would like to change to a client-server architecture in the future, decoupling the UI from the functional code. From this discussion, I know that the best way to approach that is to define an API for the two to communicate that can be passed over a network. Now the fun part starts where I need to figure out how to best achieve that with the tools that LabVIEW offers.

-John

[Grampa_of_Oliva_n_Eden]

I don't know where you are going with this good vs bad thing. Decoupled code is not necessarily good and strongly coupled code is not necessarily bad. No one is trying to make those kind of judgments here. What we are trying to do is define what coupling is and what the benefits and pitfalls are.

Most of the discussion has been surrounding what decoupling means. In that area, there has been some disagreement but I think we have come to a reasonable conclusion.

For me, this has been helpful because I can now look at my designs and ask myself: "will decoupling offer any benefits to this project?" and "what steps will I need to take to decouple the UI from the rest of the code".

Right now I have a strongly coupled design that I would like to change to a client-server architecture in the future, decoupling the UI from the functional code. From this discussion, I know that the best way to approach that is to define an API for the two to communicate that can be passed over a network. Now the fun part starts where I need to figure out how to best achieve that with the tools that LabVIEW offers.

-John

I don't know where I am going myself.

From what I have read on OOP Coupling is something to be avoided (i'll let let experts say why). So if Coupling should be avoided then de-coupling appears to be a goal that I should work toward in my designs.

But a a "sanity check" alram goes off when I try to fit the idea of complete decoupling and performance into my head at the same time since there seems to be a contradiction.

Maybe its just me being paranoid (again).

Please don't take offence in my reply. I am just thinking out loud and trying to learn as I go.

Ben

[Daklu]

From what I have read on OOP Coupling is something to be avoided (i'll let let experts say why). So if Coupling should be avoided then de-coupling appears to be a goal that I should work toward in my designs.

Yes, that is typically what they say and as a general rule of thumb, they are right. Programmers not trained in software engineer or familiar with OO thinking often create tightly coupled applications. What they should say is, "unnecessary coupling should be avoided." Too much coupling makes it hard to change the software. What they should also say is, "unnecessary decoupling should be avoided." Too much decoupling makes the code harder to follow and may impact performance.

How much decoupling is "enough?" If you can easily make the changes you want to make it is enough.

[Grampa_of_Oliva_n_Eden]

Yes, that is typically what they say and as a general rule of thumb, they are right. Programmers not trained in software engineer or familiar with OO thinking often create tightly coupled applications. What they should say is, "unnecessary coupling should be avoided." Too much coupling makes it hard to change the software. What they should also say is, "unnecessary decoupling should be avoided." Too much decoupling makes the code harder to follow and may impact performance.

How much decoupling is "enough?" If you can easily make the changes you want to make it is enough.

Thank you.

I'll quote one of my buddies grandmother

"All things in moderation, including moderation."

Ben