Well, there are all kinds of "business logic", from formatting to calculations to validation to persistence. Here's a very simple example, using formatting. The bean is called Name, and supports three attributes: first, last and middle. There are getters and setters for each attribute. However, there is also one additional getter, getFull, which will return the formatted full name. For example, if the name attributes are "Joseph", "Dominic", and "Pluta", the getFull method will return the value "Joseph D. Pluta". This is the "business logic" for the Name method, and is encapsulated in the bean.
Ugh. Okay, now you're to the point of making very fine distinctions. I probably shouldn't have used a formatting example. If you wanted something specific to business logic, you would have something like this:
The business rule in place here is that the order line is only taxable if the item is taxable. Thus, the total taxable amount only includes those order lines whose items are taxable. Now, in this particular case the ultimate decision as to whether something is taxable is in the Item class. However, in other businesses, other rules may apply. That's what makes generalizing business rules so difficult. Joe
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop