Talk:Code Against Interfaces, Not Implementations

From APIDesign

---

Revision as of 05:51, 14 June 2008

Done: e368fc1dbe72

The sentence "Imagine that NetBeans had used a different signature for the aforementioned method..." is a bit hard to read, mostly because of "different". Instead, consider something like "If the NetBeans getCause method had been defined with a Throwable return type, it would have ended...".

--AndreiBadea 09:43, 7 April 2008 (UTC)

Done: cd866eaf3b80 - I've explained something but not all the details. Still you need to know at least a bit of knowledge how the VM stores the objects, or you need to trust me that I know.

Your comparison of multiple inheritance and delegation is unclear. Just how could I use delegation instead of multiple inheritance, and why would this require 16 bytes of memory per interface? This needs to be significiantly expanded for clarity.

--AdamDingle 00:38, 13 April 2008 (UTC)

Done: 24bf47daa023

The "public final class InstanceProvider" does not make sense as written. The whole point of InstanceProvider is that it is something that has to be implemented, as well as called. If there were the InstanceProvider and BetterInstanceProvider interfaces as before, and a separate final API class (or static utility methods), the point would be made.

--JesseGlick 00:59, 8 April 2008 (UTC)

Done: a578de6e7ceb agreed but not in such strong way

Static factory methods can be put into a separate noninstantiable class:

public interface Tweeter {
  void tweet();
}
public class Tweeters {
  private Tweeters() {}
  public static Tweeter softTweeter() {...}
  public static Tweeter loadTweeter() {...}
}

so this is no real argument for making Tweeter be an abstract class.

I would offer a grave warning against putting protected abstract methods into an interface. In practice I have usually found such methods to be a mistake. For example, it makes it impossible to create a proxy implementation that just adds some aspect such as logging.

--JesseGlick 01:07, 8 April 2008 (UTC)

Done: f1d73f9490a0

The Request/Response example has a few superfluous usages of this. Or perhaps you prefer to prefix all field references with this -- that's fine, but it should be done consistently.

Page 97, para 1: "trampoline pattern" should probably be "friend accessor pattern".

--AndreiBadea

• C'mon Andrei, that is an implementation detail, from point of API this does not matter!

--JaroslavTulach 12:31, 7 April 2008 (UTC)

Right, the API couldn't care less. But I believe that if the book isn't polished, its credibility will suffer. I haven't seen much inconsistency in, say, Effective Java.

--AndreiBadea 19:50, 7 April 2008 (UTC)

• Which is probably because effective java is about coding and not about APIs.

--JaroslavTulach

I would like to second Andrei's point. Even bad indentation in an example in a book greatly diminishes its credibility.

• Hmm, ok.

There is a minor potential problem with this Request/Response pattern: there is no guarantee that the Compute implementation will not hold onto the Response object after the computeData method is called. The caller should immediately copy the fields out of the Response object to be sure.

• Solving it is easy - add final close() {...} to Response, but that complicates the example, and anyway belongs more to runtime aspects of an API

--JesseGlick 01:19, 8 April 2008 (UTC)