Pass information back from called form (4 Viewers)

[MarkK]

Tight-coupling defeats scalability. They are inversely proportional.

 

[Pat Hartman]

Tight-coupling defeats scalability. They are inversely proportional.

What does scaling mean in your sentence? Does it mean that the function/class will be used by different forms/reports in the future or that the function/class can be modified to do additional things? Nothing I suggested violates the first definition. But the second definition is the road to unintended consequences. The calculation performed by the class/function uses fldA and fldB. I don't use sloppy names in my application so I don't have to worry about not being able to use the class/function with a different form/report because the necessary variables will have consistent names. So my function is infinitely scalable as long as I don't expect it to work on fldC and fldD.

Simplicity reduces the potential for bugs. The code being called has a specifically defined purpose. If you change its purpose, you should probably build a new class/function rather than having to go back and find every piece of code that references the class/function to determine if the change to the calculation will cause a bug in some cases because one of the values is not available or return invalid results because originally, the function was returning the subtotal before tax and now you want to change it to return the total including the tax. Think about all the times you have updated Access and some bizarre feature breaks like your reports all revert to currier as their font? I seem to remember something stupid that a few years ago. Why did that happen? It is important to avoid a ripple effect. It is better to make a new class that takes the additional variable and finishes the calculation after executing the original class/function.

If a class is used only by forms/reports you can have each form/report pass 3 variables or however many the function/class required or you can pass the function/class the object (form or report) and let the function/class get its own data. If it turns out later (remember scalability) that the function/class now needs a 4th variable, think about the changes (ripple effect) that are required if I am specifically passing variables vs what needs to change if the class/function can get the 4th variable by itself. I change potentially dozens of forms to alter the calling parameters or I just change the class/function.

A class/function simply cannot be all things to all people. It does what it does and scalability does not affect it. It is only when you try to reuse objects in unintended ways that you run into problems with scalability.

 

[MarkK]

Sorry, I meant extensibility, not scalability. Tight-coupling defeats extensibility.

 

[Pat Hartman]

Sorry, I meant extensibility, not scalability. Tight-coupling defeats extensibility.

A class/function does what it does. It doesn't do something else. You can't use it out of context. If it needs arguments a and b, that's what it needs. If it returns c, that's what it returns. if you change any of its inputs/outputs, all procedures that invoke it also need adjusting.

 

[pdanes]

If that is your take away I missed making my illustration. It was not to point out a shortcoming in a persons position but to illustrate that coupling is a sliding scale vice a binary level.

No argument there. Very few non-trivial categories are easily definable in such a way that any particular item can immediately be assigned to the proper one.

Now to be truthful if I am really going to do this I am probably going to build public property accessors to pull/push data to/from controls such as shown in step 4 and raise custom events to return data like step 5. So that would seem pretty loosely coupled IMO, but is it good enough? I think that question is contextual.

Even 'good enough' is hard to define. I agree that setting up public property routines in a form is preferable to having outside code reach back and manipulate a form's objects directly, except of course, for routines that are specifically built to do exactly that. For instance, I have a whole host of routines that set various properties of form elements, rather than doing it manually. It is cleaner and faster to code something like:

gbl_ctlsEnable arr:=array(txtbox1, txtbox2, txtbox3, txtbox4, ...)

than it is to put all those individual assignments inline. Code like that obviously DOES reach into my form and make changes. But you could also argue that even the actual assignment statement enables foreign code (the VBA code engine) to manipulate 'my' form elements, which of course is an absurd argument, but the statement of it is true.

Overall, I guess I'd say it's more about general principles than whether any specific line of code that is or is not acceptable to a specific schema.