The Artima Developer Community
Interviews | Print | Email | First Page | Previous | Next
Sponsored Link

Josh Bloch on Design
A Conversation with Effective Java Author, Josh Bloch
by Bill Venners
First Published in JavaWorld, January 4, 2002

Page 1 of 19  >>

Advertisement

Summary
On Monday, December 10, 2001 Bill Venners visited the Sun Microsystems campus in Santa Clara, California to interview Josh Bloch, an architect in the Core Java Platform Group. In this interview, Josh discusses many aspects of design.

Over the past several years, Sun Microsystems Architect Joshua Bloch has designed major enhancements to the Java APIs and language, specifically for the Java Collections API and the java.math package. Most recently, he lead the expert groups that defined Java's assert and preferences facilities. In his 2001 book, Effective Java Programming Language Guide, Josh distilled his wisdom into 57 concrete guidelines for designing and implementing Java programs. In this interview, Josh discusses API design, extreme programming, code quality and reuse, refactoring, defensive copies trust, forgiveness, immutables, documenting for inheritance or disallowing it, copy constructors, factory methods, the equals method, and more.

Why API Design?

Bill Venners: In the preface of your fine book, Effective Java Language Programming Guide, you write that you tend to think in terms of API design. I do too. If I were managing a large software project, I would want to decompose it into subsystems and have people design interfaces to those subsystems -- interfaces that would be APIs.

Considering that, how does an API-design approach contrast with the popular extreme programming approach, and to what extent should API design be the norm in software projects?

Joshua Bloch: In my experience, there is too much monolithic software construction. Someone says that he wants to design a record-oriented file system, and does it. He starts designing the record-oriented file system and sees where it leads him, rather than follow this decomposition you speak of. Decomposition into subsystems is important, but as important is to have each subsystem be a well-designed, freestanding abstraction. That's where I feel like a preacher on a soapbox.

It's much easier to avoid turning the subsystem into a reasonable component. In particular, it's easy to let reverse dependencies creep in, where you write the low-level subsystem for the use of its initial higher-level client, and you let assumptions about that client creep downwards. In the case of less experienced programmers, it's more than assumptions. You let variable names creep downwards, and you let specific artifacts of that initial client creep into the allegedly lower-level reusable component. When you finish, you don't have a reusable component, you just have a piece of a monolithic system.

You want to weaken that coupling such that the subsystem can then be reused outside of its original context. And there are all sorts of reasons for doing that, which I go over in my book. You write something for one use, and it subsequently finds its major use elsewhere. But that only works if a subsystem is a well-designed, freestanding abstraction.

Page 1 of 19  >>

Interviews | Print | Email | First Page | Previous | Next

Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us