По моему опыту с такими вещами, именно деловые люди определяли правила того, что было приемлемо как совпадение, а не как техническое решение.Это имело смысл для меня, так как бизнес берет на себя риск.Кроме того, то, что составляет совпадение, может быть подвержено изменениям, например, если они используют систему и обнаружат, что слишком много людей исключено.
Я думаю, что ваш первый подход имеет больше смысла в том, что если вы можете сопоставить кого-то по имени и номеру банковского счета, то вы почти уверены, что это они.Однако, если не совпадают как имя, так и информация о банке, но адрес, телефон и все, что совпадает (например, супруг (а)), тогда система подсчета очков может неправильно соответствовать людям.Я понимаю, что это много кода, но пока вы извлекаете фактический соответствующий код (метод matchPhoneNumber и т. Д.), То все в порядке с точки зрения дизайна.
Вероятно, я бы сделал еще один шаг и вытащил сопоставление в перечисление, а затем получил бы списки приемлемых совпадений.Вроде как это: интерфейс Match {логические совпадения (Customer c1, Customer c2);}
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}, ...
};
И тогда код, выполняющий проверку, будет просто перебирать массив validMatches и проверять их, чтобы определить, подходит ли он.Я мог бы даже вытащить списки действительных совпадений в файл конфигурации.Это все зависит от уровня надежности вашей системы, хотя.