Eric said:
"Believe ten percent of what you hear, fifty percent
of what you read, and ninety percent of what you see."
Unless and until "some guy" advances an argument to
support his interpretation of the One True Way, I'd suggest
classifying him in the other ninety percent of what you hear.
(In other words, *I* feel no obligation to defend the
extravagant opinions of some unnamed religionist. If you
want to hear his opinions defended, ask him directly.)
At issue are the definition of "object-oriented language" and "100%", and
whether 'static' members violate either of those. "Some guy" (who?)
apparently believes that "100% object oriented" requires that absolutely every
referent be a member of a class instance, and that only class instances count
as "objects". If that is his position, then by those criteria Java is,
indeed, not "100% object oriented", but that still begs the question of
whether anything is wrong with that.
However, classes are themselves objects, so 'static' members are enclosed in
objects and that therefore Java is "100%" object oriented. That still begs
the question of whether anything is wrong with 'static' members.
There are dangers associated with 'static' members to which instance members
are more immune, because 'static' members are more nearly global than instance
members. Many pundits argue that global constructs are Bad Things, so some
will tell you that 'static' members are therefore Bad Things.
Others take a more pragmatic viewpoint - that certain attributes and behaviors
do not depend on specific instance state, and therefore can reasonably assume
class scope. Consider constants:
public final class Utility
{
public static final int MAX_PERCENTAGE = 100;
}
It just isn't reasonable to demand instantiation of multiple objects every
time one needs to know the 'MAX_PERCENTAGE'; it makes much more sense to give
such a thing class scope.
Non-constant entities also are useful at 'static' scope, for example, the JPA
'EntityManagerFactory' used by an application:
public final class JpaUtility
{
public static final PUNIT = "punit";
public static final EntityManagerFactory EMF =
Persistence.createEntityManagerFactory( punit );
}
For a given data store with given connection parameters (i.e., for a given
persistence unit), there's often no real need to have more than one entity
manager factory, so it's suitable to define the factory as 'static'.
(However, 'EntityManager' instances should not be 'static'.)
There is a grey area between what clearly should be 'static' and what clearly
should not be. Opinions differ, but personally I tend toward non-'static'
members when there is ambiguity.
One must be careful when defining mutable 'static' members, especially when
multiple threads are involved. The same is true for instance members, but the
latter are easier to control. If client A modifies a member, then client B
modifies the same member, then client A reads the member, there can be confusion.
