I was watching some Uncle Bob video some day which talked about how to design the architecture of a system. In that video, he gave a case study of a payroll system, I found the souce code and it is actually implemented in C++, so I ported a Java version. This is a very good example because it feels more realistic than most dummy demos out there. It also shows how to use POJO classes to layout the foundation without going too much into peripheral details like database.
I couldn’t remember who said that one of his favorite refactoring techniques is Replace Nested Conditional with Guard Clauses. When I looked into it, it did put a smile on my face despite its simplicity. This is NOT about coding aesthetics, this is all about clarity. A method has conditional behavior that does not make clear the normal path of execution. Use guard clauses for all the special cases. double getPayAmount() { double result; if (isDead) { result = deadAmount(); } else if (isSeparated) { result = separatedAmount(); } else if (isRetired) { result = retiredAmount(); } else { result = normalPayment(); } } double getPayAmount() { if (isDead) return deadAmount(); if (isSeparated) return separatedAmount(); if (isRetired) return retiredAmount(); return normalPayment(); } So much better!
It is very common in relational database that we have the following structure: A customer table has columns: customer-id, name. And an order table has columns: order-id, customer-id, order-date. See that there is a customer-id in the order table, so that we can use it to get orders belongs to a certain customer. But there is no knowledge about the orders in customer table. This is fine with database, but if we try to map this directly to java classes, we may end up with something like this:
