True OO (Object Oriented)

• Don’t go forcing your design into a pattern just for the sake of using a pattern. Simplicity should be your first concern, but if it’s a toss-up between your approach and an equally complex, well-known, standard design pattern, go for the pattern.
• Keep Variable Scope as Small as Possible; Reduce the Visibility of Things As Much As Possible
• Code to interfaces. Declare a variable, return type, or argument as an interface type rather than a specific class type. Using an interface as the type lets you expose only the definition of what your code can do, and leaves the implementation flexible and extensible and maintainable.
• Use abstract classes when you need implementation functionality.
• Less is more. Whenever you see a nested if or anything other than very simple logic flow in a method, you should seriously consider redesigning that method or splitting functionality into separate methods.
• Classes (and thus the objects instantiated from them) really should be specialists. They should do the kinds of behaviors that a thing of that type should do, and no more, no less.
• All methods should be non-static unless you have a truly good reason to make them static. OO (Object Oriented) means objects all the way down.
• Do not reinvent the wheel, and do not use any libraries other than code you developed and the core APIs. It isn’t worth giving up the benefit of using standard classes that others are familiar with, and that have been extremely, heavily tested in the field.
• Catch Low-Level Implementation Exceptions and Throw a Higher-Level Business Exception.
• Limit Subclassing. Using HAS-A rather than IS-A relationships.
• A solid, maintainable design is always look for an existing solution first!