Later, as more software was developed, programmers noticed that *understanding* what was happening during a GOTO/GOSUB was easily forgotten. Later, GOTO was recognized as a face of evil so better to use procedures which have a name, and this name provided meaning. Adding to the bargain, procedures defined variable scope so we didn't have to worry about creating unique variable names across the whole of the application. Everything was packed in a package of meaning, parameters, procedure, and scope.
Although programmers rejoiced, because the habits of those who had been using assembly had trouble adapting to the new paradigm, the new languages left a crunch behind in the form of GOTO. So many still built code with GOTO and big comment blocks to explain the intent of their GOTO blocks. As time passed habits evolved and people made their GOTOs to GTFO.
OOPS!
Later, actually much later in computer years, some smart people wanted more sophisticated control of variable scope and designed object oriented languages. These languages allowed grouping together of procedures with scope and classifying the groups with a meaningful names. These languages dropped GOTO and cousin GOSUB because by this time, it was accepted that they did more damage than good
But friends, nothing shakes confidence in a design more than seeing static. Unlike previous keywords such as GOTO and GOSUB, static begets more static design. Like a cult of evangelicals, static methods insist on converting everything they touch into static. One static method begets another, and that one begets another until as far as the eye can see are static fields and static methods in a hulking procedural design that shuttles behavioraless data structures through static methods with long parameter lists. Each static method "switch and casing" to discover state so a valid response can be made. Where OO design encourages co-locating state with related procedures in a way that minimizes scope, static data structures global to the process are bandied about, convenient for communicating state for a few static methods but unfortunately turns into a "what's good for the goose is good for the gander" mess that is shared across all kinds of activities, increasing coupling, making the application a devil to add features to or unit test.
When can using STATIC be righteousness?
I most often use "final static" to create constants. Outside of that, I think really hard before I type the words STATIC. How do you know you're in trouble?- If at the top of many of your class declarations you have STATIC initialization blocks.
- If at any moment in your code you could have a reference to a STATIC class that couples you to some heavy I/O services (DBs, network, filesystem) that'll screw you when you want to write some unit tests.
Static methods force a procedural design--a style that is as 1970s as brown wall board, orange shag, and bitchen fros. And some dirty hippies always hitch a ride: static variables (as
opposed to constants) and big global data structures. Although it's cool to throw on bell bottoms with an Atari T, and tuck a comb in the fro, fatty procedures with comment blocks every 100 lines is about as cool as banging your junk against the knob ridden dash of a classic Chevy Impala. It's only funny when it happens to somebody else. So unless all other avenues are exhausted, don't use static. And even then, minimize it's linkage by using the Singleton pattern which is unit test friendly.And remember to tell Mom, "Thanks." She'll love you even if you use static, but your co-workers and sustaining team will love you a LOT less.
Other Sources
Technically correct article:http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil
Technically correct AND entertaining:
http://blog.goyello.com/2009/12/17/why-static-classes-are-evil/
No comments:
Post a Comment