Object Calisthenics - reducing to two attributes

Question

I'm refactoring an expense tracker system using Object Calisthenics. I'm able to bring my Class down to five attributes. How do I go forward from here?

This is my class right now.

public class Expense {
    private Identifiers ids;
    private AmountInCurrency amountInCurrency;
    private Remarks remarks;
    private UserList userList;
    private ExpenseDate expenseDate;
} 

Identifiers has attributes expenseId and reportId

AmountInCurrency has an amount and a currency

Remarks has a string with remarks.

UserList has a List which is List as User has only userName (String).

ExpenseDate is a Date object.

Also I have a sql database where i'm storing the contents of the Expense object. Should I directly pass the expense object and retrieve the primitives or should I create an entity object which takes this expense object as a constructor argument?

NOTE : This is not production code, I'm doing this just as an exercise.

Answer 1

Object Calisthenics are simply theoretical exercises, which provide a good way train programmers to write cleaner code. This means that:

1. You shouldn't use Calisthenics when writing production code. Those are not best practices, and not even guidelines for production code.

2. There would always be counter-examples, i.e. cases where applying Calisthenics would lead to bad code. For example, there are numerous cases where code which uses else keyword would be much simpler than inheritance.

In your case, the object looks pretty clear. You may put some of its properties into objects and inherit from them or use them as properties, but probably in your precise context, it would only lead to:

• More code,
• Harder to understand architecture,
• Difficulty to apply other Calisthenics, like, together, keeping entities small and using one dot per line.

For example, you may start by doing the following:

// One property less.
public class Expense {
    private Identifiers ids;
    private AmountInCurrency amountInCurrency;
    private UserList userList;
    private ExpenseDate expenseDate;
}

public class CommentedExpense {
    private Expense expense;
    private Remarks remarks;
}

---

Following the comments to the original question, I think it's useful to detail a bit the context and the goal of Object Calisthenics.

The original paper (RTF document) is not absolutely clear on the subject, but much clearer compared to some of the websites and articles of Object Calisthenics adepts and followers, who make others believe that everyone should follow the described rules every time, everywhere.

Here's a relevant quote from the document, emphasis mine:

Do a simple project using far stricter coding standards than you’ve ever used in your life. Below, you’ll find 12 “rules of thumb” that will help push your code into good object-oriented shape.

By suspending disbelief, and rigidly applying these rules on a small, 1000 line project, you’ll start to see a significantly different approach to designing software. Once you’ve written 1000 lines of code, the exercise is done, and you can relax and go back to using these 12 rules as guidelines.

This is a hard exercise, especially because many of these rules are not universally applicable. The fact is, sometimes classes are a little more than 50 lines. But there’s great value in thinking about what would have to happen to move those responsibilities into real, first-class-objects of their own. It’s developing this type of thinking that’s the real value of the exercise. So stretch the limits of what you imagine is possible, and see whether you start thinking about your code in a new way.

In other words, the intention of the original author was never to incite people to use those rules for production code. Those rules have only a theoretical goal.

I've found it to be pretty useful for the programmers with years of experience who still write 500-LOC functions with 15 embedded if/for blocks. Applying Object Calisthenics on a tiny project is a good way to make them discover professional programming, give them basic habits they may then follow for production code and awake their curiosity to make them search for design patterns, inheritance, Dependency Injection, etc.