Question
I have heard many times the term "logic" or "business-logic" in discussions about software development. For instance:
- (about unit-tests) it's not necessary to achieve 100% code coverage, testing of logic is god enough.
- (about web applications architecture) controller should not contain any business-logic, it only should call other classes's methods.
- VIEW layer (e.g. JSP files) should not contain any business logic
Now tell me, what is "logic"? Does it mean any IF in code? But, I don't think that code without IFs ever existed. Or "business-logic" means any information that came from client? Actually I believe that all what we do is initiated by client, so all our code does contain information from client. That's why I never could understand what the fuck is "business logic".
Answer
Probably this question could be easier answered if you use term "knowledge" instead of "logic". "Logic" is any
knowledge about the code, or about how your code should behave. It may be also expressed like "logic is anything that you ever wanted to comment".
Example
Let's consider class Account for example.
Once upon a time Internet connection disappeared from our office for two hours. I actually could not work because SVN, jira, dabase etc. were not available. And I decided to exercise in writing unit-tests. So I found class Account:
public class Account
{
// Negative amount means that account is prepaid
private BigDecimal amount;
public BigDecimal getAmount() {
return amount;
}
// And 20 getters/setters more
}
At the first glance, is there anything to test? Is there any IFs? Is there any logic? It seems that no. No logic, no IFs - nothing to test. I wanted to skip this class and find something more complicated, but eventually got sight of the comment near the
amount field:
Negative amount means that account is prepaid
Wait, what is that?
It turns out that the
amount is a total debt of the client, and if the client has made an advanced payment, then this "debt" is negative. Well, this is some knowledge about the code. Let's try to
convert this comment to unit-test:
public class AccountTest
{
@Test
public void negativeAmountMeansThatAccountIsPrepaid() {
Account prepaidAccount = new Account(-123);
assertTrue(prepaidAccount.isPrepaid());
}
}
Since we check for negative
amount, it also would be reasonable to check for positive
amount:
@Test
public void positiveAmountMeansThatAccountIsInDebt() {
Account indebtAccount = new Account(456);
assertFalse(indebtAccount.isPrepaid());
assertTrue(indebtAccount.isInDebt());
}
We have eventually got two new methods
isPrepaid and
isInDebt, which implementation is of course straightforward for you:
public class Account
{
private BigDecimal amount;
public boolean isInDebt() {
return amount > 0;
}
public boolean isPrepaid() {
return amount < 0;
}
}
You see, we have got IF's in our code!
What's next? You should have thought: probably, these IF's already were somewhere in the code?
I had to search for such IF's for a while, but it was worth it. These IFs were in JSP files, which is the "view" layer, which should not contain any business logic by definition:
<% Positive amount means that account is in debt %>
<c:if test="${account.amount > 0}">
<span style="color: red;">Please pay your debt!</span>
</c:if>
<c:if test="${account.amount < 0}">
<span style="color: green;">Advanced payment</span>
</c:if>
Wow, we have found the second test-case. Cool. Now, since we have methods
isInDebt and
isPrepaid, we can abandon logic in JSP:
<c:if test="${account.inDebt}">
<span style="color: red;">Please pay tour debt!</span>
</c:if>
<c:if test="${account.prepaid}">
<span style="color: green;">Advanced payment</span>
</c:if>
Is it better? I believe it is. This is
encapsulation - hiding the implementation of logic from outer code. Class Amount is the only in the whole world who knows how to define, if client is in debt or has advanced payment. Other code doesn't ever know how it happens - it can get resulting boolean throught methods
isInDebt and
isPrepaid. Theoretically "in debt" and "advanced payment" information could be stored in different columns, or event different tables, or even different databases. Nobody knows. Thanks to two methods, this logic is encapsulated in class
Account.
If you still don't believe, compare code size:
Before
<%-- Positive amount means that account is in debt %-->
<c:if test="${account.amount > 0}">
<span style="color: red;">Please pay your debt!</span>
</c:if>
|
|
After
<c:if test="${account.inDebt}">
<span style="color: red;">Please pay your debt!</span>
</c:if>
|
You can go further and create two different methods
getPrepaidAmount() и
getDebt() instead of method
getAmount(). Additionally they can check, if the client has really debt or advanced payment. As a result, it's impossible now to write a code like this one:
<%-- No matter if you have advanced payment,
I still think that you are in debt! %>
<c:if test="${account.amount != 0}">
<font color="red">Please pay your debt!</font>
</c:if>
Ideally, method
getAmount() should be removed. This would be the real
encapsulation: hiding of data and code and making them available only throught API. I think I would remove all of 20 other getters/setters if internet connection wouldn't get back to our office that day.
Moral
As You see, unit-tests lead you to readable, object-oriented code. Are you still thinking that your code doesn't contain logic? Are you still thinking that you code has nothing to test?
Of course it has!
Сообщения
