pooba,
Whatever you do you have to think about friend and public protection.
I like the friend protection, that allows the use of data inside a project
(this is of course as long as your solution exist from one project).
You have only to focus on the class/object from which you want data.
Therefore as you make in your let say formX a field or better property.
Friend TheFieldToUseByOtherForms as String
You can in most situatisons do
dim frm as formX
frm.Show...........
TheInformationIWantFromFormx = frm.TheFieldToUsByOtherForms
frm.Dispose
Be aware that there is only one form on a time active, sometimes you want
this in the situation
frm1 <-----> frm2
You want to be active in frm2 but show information in frm1. Than you make a
field in frm1 friend and changes that from frm2.
I hope this helps,'
Cor
"pooba53" <
[email protected]> schreef in bericht
- Show quoted text -
I'm going to have to throw in a caveat about Friend fields.
In my thinking, *fields* should *ALWAYS* be private unless you have an
utterly compelling reason to make them visible outside the class.
Forms are just classes. Make them private, and create accessor
properties that other classes use to read them.
You *never* want to risk someone changing the value of that field
without your consent. If it's a field, you have no control over when
it's changed; it's volatile. Trust me--if you dangle it off the form
as a field, someone, somewhere, WILL change it simply because they
CAN. There's nothing to prevent them from doing so.
With a property to wrap it, you get the benefit of control over it's
value. You can validate it, ensure that it's not null, range-checked,
valid for the context of the task at hand, and so on. You don't have
to make the field public; mark it Friend if you want to. In fact, mark
the entire class Friend if you like. But avoid exposing a field as
anything but private unless you have an *utterly compelling* reason to
do so.
Folks will tell you about things that the compiler will do for you
automatically; optimizations that will be made and so forth. Do NOT
let the compiler make those kinds of decisions for you. Make them
yourself; that way, you KNOW that you have control over the variable's
value, and you KNOW when you test that piece of code EXACTLY what the
variable's value is at all times. You'll know where it came from, what
it is, and that it's valid at any given point in time.
Sure, it's a little extra coding on your part. But isn't that little
bit of extra effort upfront worth the sure knowledge during testing
and debugging later? It's one less thing that you have to doubt when
you are testing your code. When someone asks you whether or not that
piece of code works, you can answer them definitively, and there will
be no doubt, because you'll KNOW. There won't be any chance that an
external piece of code changed the variable's value.
If you leave it as an exposed field, have you tested for the condition
where someone changes it from outside the class? If not, you may be in
for a nasty surprise when it does happen, and those defects are
notoriously difficult to track down, because it's pretty darned
difficult to figure out who changed that value. And once you figure
out that someone has changed it, how do you gracefully recover from
that situation? Which party is wrong? Your class? Or the one trying to
change your class's field? After all, by implication, fields aren't
read-only unless you've marked them that way--they're read-write:
they're MEANT to be modified. It's only logical to assume that they
can be safely changed by the caller.
But you're trusting that variable to have a known value that doesn't
change. So PROVE it. Make it private, and control access to it.
Having said all that, that's just the way I write software. Other
folks have their ways of doing things, and that works for them. I've
simply learned over time to never trust a variable if I can't *prove*
it's authenticity and stability while I've got it. So I lock it down.
Others may have very good, very sound reasons for doing otherwise. But
my guess is that those reasons are the exception and not the rule;
exposing fields to other classes should be done very rarely, and when
done so, with great care. The reasons for doing so should be
documented quite clearly. You want to explain how such a change will
impact the code. I would even suggest that instead of exposing the
field, you'd still hide the field, and provide wrapper methods that
allow you to ensure that valid values go into it. You just never know
what someone's going to put into that variable. It's just not safe to
assume that someone's going to put the value you need into that
variable.
Just a few things to think about.
Mike
