6 ideas for really bad Java API design
Here’s some tips if you want to write a Java API thats really hard work to use. Doubly so if you want to hit it with the “object oriented for evar!” ugly stick.
- Hide everything! – even the stuff that doesn’t make sense and is guaranteed to be there. Make the user jump through as many levels of indirection as possible to access anything.
- Require Casts! – make sure you use has to cast everything from an interface to a real class before they can do anything. Double points for not making it guaranteed that the objects you’re casting will always be what you’re casting them to.
- Make everything an interface! – always always make everything an interface. Ideally a hierarchy of interfaces that don’t add more than one or two features at each level. Especially good for misleading your user.
- Wrap everything! – related to 3, make sure you’ve wrapped even the simplest of data types in an object – thats always good for memory consumption and is extra effective if you use non-standard naming.
- Runtime Analysis! – while it’s important to wrap anything and everything in an object, don’t make fields visible. Ideally put them in a generic map even at the lowest most specific level of your ornate object tree. Thats reusable and meta right? Make sure the user has to either read the source or use a debugger to determine what the fields are called.
- More code is better! – make sure your user has to write as much code as possible even for the most common use cases. The more code they have to write the more they’ll appreciate the beauty of your API.
We all love object structures and we all love “beautiful” code. However when you’re writing an API it’s about matching the use cases and make the developer productive. Please don’t make them jump through hoops for the sake of your “elegance”.