-- This entry is unfinished, but I'm releasing it as I don't find the time to finish it. Maybe I will update it later ---

• Write down what the library should do and take care that she only do what you have defined
• Avoid cross dependencies: it's up to your application to use the lib, not to the lib to know the application -> provide container with your lib that applications can use for data exchange
• Construct classes from the outside in: write first a sample app that use your lib. This will help you to identify what your lib need. See [2]#
• Extensions: a commonly error with own libraries is that at the beginning they are well designed. Than comes the need for more functionality which is not directly par tof the library, because it is easier to adapt the library. Quickly you will have things in your library which shouldn't be in and also might have dependencies to other libraries which shouldn't be (because you need it for the new functionality). Better is to give the application which use your library the ability to extend/customize it. One easy way is to use abstract classes which must be implemented by the application
• Debugging: see [1]
• Encypsulation: users shouln'd know how your lib works internally
• Constants: what if you want to share constants accross your applications and libraries? unfinished
• Use classes for constants, not interfaces (this is not what they are thought for). This implies: don't "implement" interface to easier use constants.
• Library versioning: unfinished
• cross lib dependencies: Application use A-Lib which use B-lib. But App also use B-lib directly, but in another version ... how to solve the problem, unifinished.