采访地址
The risk of speculating
Bill Venners: The GoF book says, “The key to maximizing reuse lies in anticipating new requirements and changes to existing requirements, and in designing your systems so they can evolve accordingly. To design a system so that it’s robust to such changes, you must consider how the system might need to change over its lifetime. A design that doesn’t take change into account risks major redesign in the future.” That seems contradictory to the XP philosophy.
Erich Gamma: It contradicts absolutely with XP. It says you should think ahead. You should speculate. You should speculate about flexibility. Well yes, I matured too and XP reminds us that it is expensive to speculate about flexibility, so I probably wouldn’t write this exactly this way anymore. To add flexibility, you really have to be able to justify it by a requirement. If you don’t have a requirement up front, then I wouldn’t put a hook for flexibility in my system up front.
But I don’t think XP and patterns are conflicting. It’s how you use patterns. The XP guys have patterns in their toolbox, it’s just that they refactor to the patterns once they need the flexibility. Whereas we said in the book ten years ago, no, you can also anticipate. You start your design and you use them there up-front. In your up-front design you use patterns, and the XP guys don’t do that.
Bill Venners: So what do the XP guys do first, if they don’t use patterns? They just write the code?
Erich Gamma: They write a test.
Bill Venners: Yes, they code up the test. And then when they implement it, they just implement the code to make the test work. Then when they look back, they refactor, and maybe implement a pattern?
Erich Gamma: Or when there’s a new requirement. I really like flexibility that’s requirement driven. That’s also what we do in Eclipse. When it comes to exposing more API, we do that on demand. We expose API gradually. When clients tell us, “Oh, I had to use or duplicate all these internal classes. I really don’t want to do that,” when we see the need, then we say, OK, we’ll make the investment of publishing this as an API, make it a commitment. So I really think about it in smaller steps, we do not want to commit to an API before its time.
Bill Venners: Well, there are speculative requirements. So if you say you’re going to wait until there’s a requirement, doesn’t that simply move the problem? Because someone could say, “Well, we’re going to need this.” They are saying that’s a requirement. But then someone else might say, “Well, do we really need this, yet?” I’m not quite sure I understand when to speculate and when not to speculate. Who decides when a requirement is really a requirement? How do I decide as a programmer?
Erich Gamma: Well, you must have a customer or consumer of what you produce. For Eclipse, our customer is the community who writes plug-ins. And so we interact with them, and also kind of sync with them, based on the concrete uses we know ourselves, what they might want to use. Therefore my recommendation to a programmer is that when you have to speculate, make sure that you have a least one of your clients involved, preferably more. It also helps when I already have something in my hand.
Bill Venners: What do you mean by having something in your hand?
Erich Gamma: I have a concrete example. And then I go and speculate about how to make it more abstract, and not the other way around. Ideally once I have speculated I immediately ask for feedback from my potential clients.
Bill Venners: So you build a concrete example first.
Erich Gamma: Maybe two or three, until it truly hurts. I duplicate the code once. I duplicate it twice. And then, wow, I had to duplicate it again. At this point the abstraction process starts. So, I say, it would be really nice if this class would allow me to plug in this custom behavior so that I do not have to duplicate the rest.
总结
1，不要过度使用设计模式。如果你的需求没有一个例子，需要你抽象扩展，那就不需要花精力去 人为设计 change point>
2, 可以先写一个实例，当发现有重复代码，开始重构。在这过程中，可以抽象，使用设计模式。
3， 极客开发模式，对效率要求极高。而前期对设计模式投入很多时间，会有点牺牲开发的效率。