9:54 a.m.
OK, here's why I think we should drop the 'm'.
Hmmmm ....OK...let me back up....
An object should conform to a contract. Once the object is created,
that contract has been signed, sealed and delivered. At least, that is
the intention. However, Java often falls down on this. We have
"Init" methods. We have Property setters that must be called before we
have a "valid" object.
Why? Java is a pretty strongly typed language. But, it needs to be
able to interface with scripting languages, and thus it has, among
other things, the reflection API. Reflection has the ability to
enumerate the properties (member variables) of the object, and to fetch
values from the object without having to have a compile time
dependency. We can even make variables that are Read Only by tagging
them as 'final'.
A final field must be defined by the time the constructor has returned.
The dependencies to decide the value for the final field must be passed
in to the constructror.
The constructor is available via reflection. the Parameters are
avialable via reflection...but....
Not the names of the parameters. This is possibly the largest oversight
in the Java language. Without named parameters, a scripting language
cannot do anything to determine which of the values it has maps to which
of the dependencies of the constructor. All it can do is try to pass
them in the right order.
So what happened?
Java has a nasty covention called the bean API. A naming convention
get<CapitalizedName> and set<CapitalizedName>. Want to make somethig
read only, drop the set.
Joshua Blcok sets out an important rule of thumb in Effective Java:
Favor Immutable Objects. An immutable object is implicitly thread
safe. The Bean API with its late initialzation of properties makes
this impossible.
However, we have hope. In recent versions of Java, the Attribute API
makes it possible to automatically build classes that let us create a
Dictionary to pass to the constructor based on the names of the
parameters. There is also the possibility of getting named parameters
into the Java standard in the future.
Regardless, this is only really an issue for scripting languages. Our
application is all Java. This means that we can use classes and type
safety to strongly associate the dependecies of a constructor with the
objects that can fulfil those dependencies. We don't need to play
"Everything is a string" like Javascript does.
We can have immutable objects, without the bean API. And we can expose
the properties of those objects as final properties instead of
get<CapitalizedName>. But this only makes sense if the names of the
properties are the "good name".
This has the potential to make code that is much more readable and
concise, while increasing type safety.
Yes, increasing type safety. If a string field is immutable, but it
needs some business logic, say to confirm that it complies with a
pattern, we create a class that encapsulated that format, and make an
immutable instance of that class. The pattern is confirmed in the
constructor. If we try to make an instance that does not conform,
throw an exception.
Here is how it is done in a beanAPI way:
public class Certificate{
String fingerprint;
String getFingerprint(){
return fingerprint;
}
String setFingerprint(String fingerprint)
throws IllegalArgumentException
{
validateFingerprint(fingerprint);
this.fingerprint = fingerprint;
}
}
Note that the logic for fingerprint is encapsulated in the Certificate
object, and cannot be cleanly separated out.
Here's the refactored solution.
public class Fingerprint{
private String internal;
public Fingerprint(String) throws InvalidArgumentException{
...
}
String toString(){
...
}
}
public class Certificate{
public final Fingerprint fingerprint;
puiblic Certificate (Fingerprint fingerprint) {
this.fingerprint = fingerprint;
}
}