Library implementation pitfalls

Question

What practices should developers avoid when implementing libraries?

For example, libraries should not use the following (or default usage should be disabled):

System.err
System.out
exception.printStackTrace
System.exit

The developer of an application needs full control over the text that is presented to the user (language being one reason of many). Some libraries write (English text) to System.err, some to System.out, and some to both! Instead, libraries should inform the application (not the user) of problems either by throwing exceptions (not printing them), observer patterns, or similar.

What else? (Suggest alternatives when possible.)

Answer 1

Must read Effective Java Second Edition, especially Chapter 3: Methods Common to All Objects (pdf).

Answer 2

To extend that list, avoid anything that depends upon global variables. Including locale and character encoding. Unfortunately some of the Java libraries ignore this, and for instance, various case-insensitive string comparisons can fail if the locale is Turkish (where 'i' and 'I' don't match). In particular avoid any static set method.

And as a corollary to that, don't add any global variables either!

Answer 3

Don't make assumptions about directory locations.

Answer 4

you could separate your lib into two jars, one pure interfaces and the other implementations.

you could provide set methods for the lib's own in, out and err streams.

you could use internationalizaton: http://java.sun.com/javase/6/docs/technotes/guides/intl/index.html

consider using creational patterns (http://en.wikipedia.org/wiki/Creational%5Fpattern), the facade pattern (http://en.wikipedia.org/wiki/Facade%5Fpattern), and any of other the design patterns (http://en.wikipedia.org/wiki/Design%5Fpattern%5F%28computer%5Fscience%29) if appropriate.

Answer 5

Sounds like you might be using Java. If you are actually using C#, do yourself a favor and start using FxCop right now.