Re: static props and methods = global variables??
From: Cowboy \(Gregory A. Beamer\) [MVP] (NoSpamMgbworld_at_comcast.netNoSpamM)
Date: 07/19/04
- Next message: Jon Skeet [C# MVP]: "Re: Performance cost of casting"
- Previous message: Cowboy \(Gregory A. Beamer\) [MVP]: "Re: Framework 2.0 available?"
- In reply to: Stu Smith: "Re: static props and methods = global variables??"
- Next in thread: John Saunders: "Re: static props and methods = global variables??"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 19 Jul 2004 11:51:16 -0500
"Stu Smith" <stuarts@nospam-digita.com> wrote in message
news:uXFvcGabEHA.384@TK2MSFTNGP10.phx.gbl...
>
> "Cowboy (Gregory A. Beamer) [MVP]" <NoSpamMgbworld@comcast.netNoSpamM>
wrote
> in message news:%23Z428X0aEHA.3352@TK2MSFTNGP12.phx.gbl...
> > The only question to ask is how often the items are going to be used. If
>
> I think it's also worth considering lifetime as well. A global variable
can
> have an unclear or badly defined lifetime, and that can cause you
problems.
In general, I try to use static items for application level processes and
kill them on the application end, so I neglected the lifetime issue. Good
catch!
> > regularly, then keeping variables in memory is not a bad thing. I
> routinely
> > use a singleton for application settings. The singleton stores all sorts
> of
>
> As an example, do these app settings ever get written as well as read? If
> not then fine, but if so you have a lifetime issue -- when do they get
> written? As another example, what if the application settings need to
change
> midway through execution?
Generally, for config objects, you are not changing them in the midst of the
application. Regardless, I am very fond of explicit coding, so I destroy the
objects when the application unloads. The only time this is not caught is
when the server dies, but that is not an issue as the memory is killed when
the server is dead.
> Many types of static/global data could really be considered a cache of
some
> sort (as in the app config example), and the golden rule there is "caching
> implies policy" -- if you can't tell me the policy, you're likely to have
> problems.
>
> (And to anticipate Mr. Beamer's reply, the policy there is probably
> 'read-only; lifetime must extend at least until last access; small data
vs.
> relatively slow access to original data makes it worth it').
Certainly, there is a trade off with any type of programming. For example,
one oft errs on the side of performance only, which is a major mistake, as
maintainability costs businesses more than performance in most scenarios.
In most cases, I would be wary of static variables and properties unless
there is a reason for them. There are so many ways to cache data in the .NET
Framework that fit most scenarios, so coding your own, if there is an
acceptable caching method, is unwise.
Static helper methods are a different issue.
The unfortunate thing about open forums is we often have to speak in
generalities due to our own time constraints. I agree with the points you
make.
> > --
> > Gregory A. Beamer
> > MVP; MCP: +I, SE, SD, DBA
> >
> > ************************************************
> > Think Outside the Box!
> > ************************************************
- Next message: Jon Skeet [C# MVP]: "Re: Performance cost of casting"
- Previous message: Cowboy \(Gregory A. Beamer\) [MVP]: "Re: Framework 2.0 available?"
- In reply to: Stu Smith: "Re: static props and methods = global variables??"
- Next in thread: John Saunders: "Re: static props and methods = global variables??"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
