Some arguments from this guy are: 1) Do not use a class if it doesnt have state Agreed 2) Keep it simple and do not think about the future, fix it later if n

Some arguments from this guy are: 1) Do not use a class if it doesnt have state Agreed 2) Keep it simple and do not think about the future, fix it later if needed He probably never wrote API code in libraries needed for other people. Once you choose something you are bound to it. In this case classes and interfaces are very helpfull. For example the API class example in the beginning (no state) is a good example. In the future the api might be extended with more functionality. The last thing you want is have 3rd parties rewrite their code cause you changed the API. So a class is good to provide a Facade (yes Facade Pattern). 3) package names are not for taxonomy but for preventing nameclashes True. However in Java the editor is so powerfull that you never ever have to lookup package names. This goes automatically (IDE parses the code on the fly). Java package names also use URI patterns like: com.google.android.hardware.vibrator. Which can only be used by somebody who has the google.com domain name. This prevents name clashes ALL the time. In python you sometimes have to rename a whole project. And the taxonomy gives you an indication what the code actually does. 4) Dont overuse exceptions and keep shorts names. Agreed. However i am not sure what the best granularity is. In a public Library API, i would be very carefull about this. Otherwise I agree with him.