contrasts the actual code: Espresso Logic vs. Traditional Hand Code.
The actual code in the following sections, and briefly summarized below.
Focusing just on the code replaced by the 5 rules, we wrote approximately 500 lines of code. This is of course in addition to the design time to work through the issues discussed here
| Class || Lines|| Notes|
| 139|| |
| 159|| |
| 155|| |
| 65|| |
See for example
sLineitem#setQtyOrdered(). The basic operation of the Service Objects is as follows:
The program must first detect what has occurred: an insert, update or delete. For updates, we also must determine which attributes change (though we have taken a significant simplification by saving changes after a single field is altered)
Next, the code must force the recomputation of dependent data. In our example:
- SLineitem#setQtyOrdered() calls #updateAmount()
- SLineitem#updateAmount() updates the amount, computes the delta change, retrieves the Purchaseorder, and calls
updateAmountTotal(delta) updates the amountTotal, retrieves the Customer, and calls
- SCustomer#updateBalance() updates the balance and calls
- SCustomer#checkCredit() checks the credit limit
There were 5 lines of logic, shown at right. Observe this is both transparent documentation, and maintainable implementation.
Traditional version - Hand-written Java
Below is the hand-written code required to duplicate the same functionality without Espresso Logic.
The business logic tends to be scattered across classes and methods. This is very brittle -- it's very easy to forget a call in a method, leading to a potentially non-obvious bug.