Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Taking your followup:</p> <blockquote> <p><em>What if this is just the "investibility" logic for a customer wishing for a business loan. Perhaps the innvestibility decision of a customer for another product is really quite different ... Also, what if there are new products coming out all the time, each with different investibility decisions and I don't want to be updating my core Customer class every time this happens?</em></p> </blockquote> <p>and one of your comments:</p> <blockquote> <p><em>I'm not entirely sure about holding logic close to the data on which it operates. The real world doesn't work like this. When I ask for a loan, the bank decides whether I qualify. They don't ask me to decide for myself.</em></p> </blockquote> <p>you are right, as far as this goes.</p> <pre><code>boolean investable = customer.isInvestable(); </code></pre> <p>is not the optimal solution for the flexibility you're talking about. However, the original question didn't mention the existence of a separate Product base class.</p> <p>Given the additional information now available, the best solution would appear to be</p> <pre><code>boolean investable = product.isInvestable(customer); </code></pre> <p>The investability decision is made (polymorphically!) by the Product, in accordance with your "real world" argument and it also avoids having to make new customer subclasses each time you add a product. The Product can use whatever methods it wants to make that determination based on the Customer's public interface. I'd still question whether there are appropriate additions which could be made to Customer's interface to eliminate the need for switch, but it may still be the least of all evils.</p> <p>In the particular example provided, though, I'd be tempted to do something like:</p> <pre><code>if (customer.getCategory() &lt; PRIME) { investable = customer.getSavingsAccount().getBalance() &gt; 1e6; } else { investable = customer.isCeo(); } </code></pre> <p>I find this cleaner and clearer than listing off every possible category in a switch, I suspect it's more likely to reflect the "real world" thought processes ("are they below prime?" vs. "are they sub-prime or mid-prime?"), and it avoids having to revisit this code if a SUPER_PRIME designation is added at some point.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload