Page 132
←Older revision | Revision as of 08:57, 27 January 2014 | ||
Line 2: | Line 2: | ||
Implementation of ''Playback'' interface should be named ''MyPlaybackPrints'' instead of ''MyCallbackPrints''. | Implementation of ''Playback'' interface should be named ''MyPlaybackPrints'' instead of ''MyCallbackPrints''. | ||
+ | |||
+ | ==== [[Errata 8|Page 134]] ==== | ||
+ | |||
+ | [[Yoshiki]] suggests to use ''is not well understood'' instead of ''not part of conventional wisdom'' as that is much clear to international speaker in the paragraph that talks why [[APIvsSPI|client/provider]] API separation is much more visible in [[C]] and very blur in [[Java]]: | ||
+ | |||
+ | In the case of [[C]], the amount of work to produce an [[SPI]], such as a callback, is enough to prevent a beginner from even trying it. Your knowledge has to grow significantly to attain a state where you can or need to design an [[SPI]]. However, in [[Java]] any declared method that is not private, final, or static is an invitation for someone to provide a callback and thus create an accidental [[SPI]]. Often programmers and teachers don’t clearly understand this. It’s not part of '''conventional wisdom''' (e.g. '''not well understood'''). Although Java books introduce public, nonstatic, and nonfinal methods in their first chapters, or at least as soon as they start talking about applets, they don’t provide proper warnings about all their consequences. Though that might be fine for simple development, when you start to design APIs, all the bad habits learned at the start come back to haunt you in the form of mistakes. | ||
+ | |||
+ | However the message remains the same: Make sure you separate [[APIvsSPI|client and provider APIs]] and [[ClarityOfTypes|clarify meaning of types]] in your API. | ||
==== [[Errata 8|Page 134]] ==== | ==== [[Errata 8|Page 134]] ==== |