I've been sitting in a lot of code reviews and code inspections where somebody suggests a change to optimize something. The response from the author is almost always; but that's premature optimization! End of argument... But I almost never hear somebody doing the opposite. I came to think about this again a few days ago when it happened again and just a few hours later I read this post about the subject.
Premature optimization is not black or white. Some things we know are bad for performance (like memory allocation and copies in a high performance C program) and nobody questions if you optimize that without actual proof it's a problem. As the post above describes it's all about paying a tax up front that is big enough to avoid a large fine later. I don't think the idea behind the quote about premature optimization is about making no optimizations. It's about making a reasonable amount of optimizations. Kind of the same kind of trade-off you have to do when it comes to writing tests. Is it worth adding a test for code that you know will pass just because to document the expected behavior? Sometimes yes, but not always as this post points out.
This time we took the completed BankOCR Kata from last time and tried to refactor it using the object calisthenics rules. It was really fun and the dojo was quite different from the other dojos which has been more TDD focus. This time we had a lot of design discussions and we had to force our selfs to just do some refactoring and see where it took us. I think it was great to see how we refactored and created new classes just to later refactor these classes to nothing and removing them. It was a great experience in how refactoring in steps reveals the design for you. We also had the full test suite save us a bunch of times from stupid bugs which is also nice.
But refactoring existing code to follow the object calisthenics rules is very hard and takes time. So there is much more work to do. We decided that we maybe want to continue this exercise later but for our next team dojo we will try a new Kata and apply the object calisthenics rules from the beginning trying to keep the code base conformed to those rules at all times. Also we want a Kata with no string parsing of two dimensional things...
We actually did another fun thing. After the dojo we went to watch D9 at a local cinema. A great finale!
This is another aspect of keeping your entities small I think. Classes with a lot of instance variables tend to have more than one responsibility. This rule may also help you create a more generic design if used correctly. For example consider you want a class representing the names (first, last and middle) of a person. Since this would be three strings you choose to represent it as GivenNames and LastName where GivenNames is another class with a list of names. Suddenly you support any number of first/middle names. So a more generic solution. End even if you don't do this and let GivenNames only have two names (First and Middle) this can be changed more easily in the future.
All that said, remember that this is a rule intended for practice, not necessarily a good thing to always use in all code.
This is a funny rule when exercising this. No class should be more than 50 lines long and no package should have more than 10 files. I guess package is a java-ism and converting to .Net I's say no more than 10 classes in each name-space. This is the rule that really makes you find the smallest responsibilities of your classes. A class that may have looked clean and with only one responsibility actually does more than one thing.
This is one of those rules you really should remember is only intended for practicing object calisthenics and not intended for "real code". At least with the hard limits of 50 lines per class. But I think the essence of this rule makes much sense in all OO design. Smaller classes are easier to grasp and more likely to have only one responsibility.
This rule has a weird name I think. What it means is that whenever you abbreviate in a class or method name you should think about why you do that. The assumption is that if you feel you need to abbreviate something it means you're using it too much. Also that a long method name typically means there is another class that could be created. A simple example would be an order object with a method "CreateInvoice". Maybe a better solution is to have an invoice object with a "Create" method.
The confusing part however is that don't abbreviate to me means writing everything out. But the explanation for this rule is that you should not abbreviate anything and each class and method name should be one or two words only. This is a fairly easy rule to conform to when practicing object calisthenics.
Not only is a long line with a lot of dots harder to understand. It usually means that your object is using not only the objects it knows but the objects their "friends" know too. Having only one dot per line does not only make your code more readable. It also helps putting the code in the right place. Consider this method:
1: public void Update()
Changing it to this is not the intention of this rule:
1: public void Update()
3: Session session = context.CurrentSession;
Rather the rule want you to do this:
1: private void Update()
And here the Update method of the context object has been left out, but it would only call Update on the CurrentSession object. All in all I think this is a rule that is suitable for production code too.
This rule states that no parameters should be a of a primitive type (e.g. int, double) nor a string. Instead new objects should be created to represent what the parameters are. Is the integer really representing money or a coordinate. This small classes also creates great places to put methods that manipulate whatever the primitive type represents.
When I first tried the object calisthenics this was one of the harder rules actually. Not by itself but because of the ninth rule; don't use getters or setters. Together it really makes you have to think about how to represent things in your code.
By itself I think this rule is one rule that easily translates to your real code. Making sure you're passing objects to your methods which actually are what they represent rather than a primitive type that represent something is generally a good thing if you some day have to change the representation. E.g. money should be a double rather than an integer.
Some people think that the if branch should be the every thing is good branch and the else branch being the error case. Others think the if branch should be as short as possible since it makes it easier to understand what would bring us into the else branch. But this rule is not about what guideline is the best. It is about putting you into a situation where you have to consider other ways to implement your conditional logic. Polymorphism and the Null Object pattern being two good alternatives.