Sponsored Link •
Bill Venners: In Refactoring you say, "I strongly believe that good design is essential for rapid software development. Indeed the whole point of having a good design is to allow rapid development."
Martin Fowler: Yep.
Bill Venners: You kind of touched on this earlier, but could you justify why you think that's the point of good design? It sounds like you're saying the only reason to have good design is to facilitate speed in development.
Martin Fowler: Yes, I think in many ways that is the case. Clarity helps you see what's in your code. You can make changes more quickly. It's harder for bugs to hide, because bugs are easier to see when the code is better designed.
Bill Venners: In Refactoring, you talk about a development team you once encountered in which each team member was publishing interfaces to others and going through lots of conniptions.
Martin Fowler: Yep.
Bill Venners: My intuition as a manager of a large team that has to build a large system, let's say from scratch, would be to first partition the system into major subsystems, then figure out the interfaces to those subsystems. And those would be published interfaces to some extent.
The interfaces wouldn't necessarily be unchangeable. Interfaces start out very changeable. Over time, they become become less and less changeable. One reason is simply the interfaces mature over time. But also, over time more code becomes married to those interfaces, and the developers become familiar with the interfaces. At some point you just have to just say, well this is the interface and move on.
Martin Fowler: You do? I don't think you necessarily need to.
Bill Venners: You eventually have to decide on an interface if you are going to publish it.
Martin Fowler: But then I argue that if you've got a team, why publish interfaces internally? To me the distinction between published and public, which I describe in another IEEE article (see Resources), is that I can't go and change the calling code of a published interface. I may realize the name of a public method isn't very communicative of what it does, that a different method name would communicate more clearly what it does. If I can find all the code that calls the method, even though it's a public method, I can change its name. In which case, I should. Published is when you can't do that. The problem in the three-person example was that they were publishing when they didn't need to.
Sun must publish its APIs. There's no way Sun can decide
List isn't a
good name, and they'd rather call it
VariableArray. It's just not something
they would want to do, because there's all that code out there relying on the name
List that Sun can't touch. But on the other hand when you've got a
development team, even with 20 or 30 people, it's not necessarily difficult to change a
name that isn't well chosen. You can change names, particularly if you've got refactoring
tools like IntelliJ or Eclipse (see Resources) that will change all the calling code for you
at the click of a mouse. It's no big deal at all.