Here's some more notes and excerpts from Better, Faster, Lighter Java. I think I'm about 1/2 done. It's still very peopleware'ish, but it easing into being more technical. Overall, it's still very good; obviously, if I'm spending so much time posting about it ;>
Facades
Our man is big into facades. And rightly so:
A facade is often the primary client of your business model. Your goal is to provide a higher-level interface for the rest of the world.
What with dividing up responsibilities and good application of DRY, when you actually get down to using code (e.g., in the UI layer), you end calling a lot of different pieces of code, passing around their return values like a cold, when all you wanted was a method like doSomething(with, these, params). This is basically the idea, implicit in Bloch,
that API's/services should be designed with usability in mind, instead of just functionality. It's great that you can code up 5 classes that users of your API have to coordinate together to update a list of, for example, purchase orders. But it'd be better if you just provided one method on a facade to do that.
Strive for Transparency
Most people use the term transparent in a very specific sense, referring to code that does a job without explicitly revealing the details of that job.
[...]Don't forget that complete transparency can often burn you, as with CORBA. Instead, create transparent services to handle course-grained interfaces, such as facades, and fine-grained services, such as your model.
Tate also discusses suggests striving for "transparency" in your systems. I was confused by this for awhile because I usually take transparency to mean "you can see all the inner workings," e.g., white box testing. But what he actually means is "invisible," as in, "a transparent persistence framework will not require modifications to the POJO's being persisted." This seems like an obvious match for one of his other principles, "keep it simple."
(The short section on using reflection to create a "transparent" persistence layer would have been a good addition to the reflection chapter in Hardcore Java.)
XML and Web services
In the early stages, even sound frameworks can become bloated and lose their value. While XML has unquestionably added some useful capabilities, its practical utility is diminishing because it's getting hard for everyday programmers to use. Web services seem to be taking this path as well.
listservs, Archiving Emal
I find email organization services like listservs to be invaluable in this respect. You can create a distribution list for "architecture and design," for instance. Then, for all decision-making emails, simply copy the "architecture and design" listserv, making a threaded repository of all decisions publicly available to the whole team.
As I always say, I'm baffled as to why most teams I've worked on don't do this. Maybe it's some limitation with Exchange (which most of them use), regulations, or just a lack of faith in email.
Previous Topic
