Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>In my experience with this sort of thing, it was actually the business people who defined the rules of what was acceptible as a match, rather than it being a technical decision. This has made sense to me, since the business ends up assuming the risk. Also, what constitutes a match can be prone to change, like if they use the system and find that too many people are being excluded. </p> <p>I think that your first approach makes more sense, in that if you can match someone by name and bank account number, then you're pretty sure it's them. However, if both the name and bank info don't match, but the address, phone, and all that matches (ie. a spouse) then the scoring system might incorrectly match people. I realize it's a lot of code, but so long as you extract out the actual matching code (matchPhoneNumber method, etc), then it's fine design-wise. </p> <p>I would probably take it a step further and pull out the matching into an enum and then have lists of acceptable matches. Sort of like this: interface Match { boolean matches(Customer c1, Customer c2); }</p> <pre><code>class BankAccountMatch implements Match { public boolean matches(Customer c1, Customer c2) { return c1.getBankAccountNumber() == c2.getBankAccountNumber(); } } static Match BANK_ACCOUNT_MATCH = new BankAccountMatch(); Match[][] validMatches = new Match[] [] { {BANK_ACCOUNT_MATCH, NAME_MATCH}, {NAME_MATCH, ADDRESS_MATCH, FAX_MATCH}, ... }; </code></pre> <p>And then the code that does the validation would just iterate over the validMatches array and test them to see if one fits. I might even pull out the lists of valid matches into a config file. That all depends on the level of robustness your system needs though.</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