Rules for Object Orientation

These constraints are intended to be excessively restrictive so as to force developers into object orientation:

1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first.

2. Don’t use the “else” keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining and every routine does just one thing.

3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify its true role.

4. Use only one dot per line. This step prevents you from reaching deeply into other objects to get at fields or methods and thereby conceptually breaking encapsulation.

5. Don’t abbreviate names. This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you’re likely to spend more time thinking about its name.

6. Keep entities small. This means no more than 50 lines per class and no more than 10 classes per package. The 50 lines per class constraint is crucial. Not only does it force concision and keep classes focused, but it also means most classes can fit on a single screen in any editor/IDE.

7. Don’t use any classes with more than two instance variables.

8. Use first-class collections. In other words, any class that contains a collection should contain no other member variables.

9. Don’t use setters, getters or properties. This is to enforce encapsulation as well as implementing dependency injection approaches and adherence to the maxim “tell, don’t ask.”