Chris brings up an interesting point... the underlying strategy. I think the strategic intension of the usage is more interesting than the pattern by itself.
Take these strategies for example (off the top of my head): 1. Use static whenever a method doesn't access attributes 2. Use static only in utility classes that don't fit the OO metaphor (e.g. - java.util.Math) 3. Use static (naively) to satisfy the compiler (Chris Bogart's example) 4. Use static only when required (e.g. - singletons) 5. Always use static until the need for an OO-approach in a module is apparent 6. Never use static because it is inherently evil (along the lines of global variables) What are the strategies being used (many of which may end up surfacing as the same patterns in source code)? And, what value-systems and training led to those patterns being formed over the career of the programmers? On Fri, Aug 7, 2009 at 12:02 PM, Chris Bogart <bog...@eecs.oregonstate.edu>wrote: > > > In TA'ing a beginning Java class last year, the most typical use of static > I saw in student assignments was actually a misuse. Students tended to blur > the distinction between a class and an object, and they'd try to call a > method, when they had not instantiated an object yet, and of course get an > error message. They'd try making the method static, which in turn caused > other errors, requiring them to make other methods and member variables > static as well. They'd basically end up with a totally static class that > they used as a singleton. In some cases that ended up being OK; but you can > see how it can lead to hard-to-diagnose bugs if you don't really understand > the issue. > > So, throwing the word static in to make the compiler happy is not a > normative usage of static, but I'd have to call it typical, at least in one > population of fledgling programmers. > > Chris Bogart > bog...@eecs.oregonstate.edu > > >
