Re: Form level Public Variables

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Jeff Mandie (jeffmandie_at_shaw.ca)
Date: 08/16/04 

Date: Mon, 16 Aug 2004 05:17:48 GMT

I couldn't agree more. Besides encapsulation though there is also the
potential for variable name conflicts as you start developing larger
applications and additional generic forms. If two or more of your generic
forms want to use the same variable names you are hooped and are forced to
modify your forms which limits their reusability.

In general I am of the opinion that you should try and avoid public
variables whenever possible. One exception I can think of is if you wish to
represent a set of enumerations for your class or form to provide a domain
for various public methods in your class or form. When doing so you should
take care to use a naming convention that will reduce the possibility of
collisions with other classes or forms.

eg. If you had a class Named MyFile that encapsulated a file instance then
this sort of thing would in my opinion be ok

Public Enum MyFileOpenConstant
    MFOpenNew = 1
    MFOpenAppend
End Enum

Public Sub Open(fileName As String, openMode As MyFileOpenConstant)
...
End Sub

"Jens Neuhalfen" <JNeuhalfen@akkaya.de> wrote in message
news:eFAnaG5fEHA.1972@TK2MSFTNGP09.phx.gbl...
> Hi Ian.
>
> (inline comments)
>
> > Hi
> >
> > I was hoping some one could give me a good reason not to use Form level
> > Public variables.
>
> Its called "encapsulation" *g*. Use "Property Get" /"Property
> Let|Set" as wrapper for the variables.
>
> One reason is that your form is totally unaware of changes made from
> the outside. This can be anything from a minor nuisance to major
> crash scenarios with added timing problems - and you don't want
> that, let me assure you.
>
> The other reason is that you somehow need to shield your properties
> - for example a negative "depth" (whatever you should need that for).
>
> >
> > I cant think of a reason why I shouldn't.
> >
> > The reason I want to use them is that I have a few almost generic forms
in
> > my application with a few subtle differences depending on how and when
they
> > are displayed.
>
> Well, this is a good design.
>
> >
> > Now to me creating a form level variable that will accept an indicator
as to
> > how the form should be displayed is rather useful.
> > And then the variable then becomes a property of the form.
> >
> > Ian
>
> HTH
>
> Jens
>
> >
> >

Relevant Pages

  • Re: Replacing new?
    ... But encapsulation itself is not related to private and protected: ... The reason is - user needs it. ... errors after that - responsible for that is fully programmer, ...
    (comp.lang.javascript)
  • Re: Replacing new?
    ... The reason is - user needs it. ... Here's a good example how encapsulation is made in Python: ... and I agree that concealing one's private parts ... // reduce sandwich size ...
    (comp.lang.javascript)
  • Re: Replacing new?
    ... use encapsulation only for encapsulation. ... Encapsulation in it's main goal is _data abstraction_, ... There's no any reason do so, ... of creating methods in constructor in hardly achieved, ...
    (comp.lang.javascript)
  • Re: is python Object oriented??
    ... Why do you need forced encapsulation? ... No one has shown a *real* reason why. ... internals that are clearly private and not documented: ... And seeing that Python is not dynamic at all, ...
    (comp.lang.python)
  • Form level Public Variables
    ... Public variables. ... I cant think of a reason why I shouldn't. ... Now to me creating a form level variable that will accept an indicator as to ...
    (microsoft.public.vb.enterprise)