Объектно-ориентированный дизайн

Я попробовал это. Я думаю, что вы не так много можете сделать, когда дело доходит до принципов объектно-ориентированного программирования или шаблонов проектирования, за исключением, возможно, использования композиции для MatchingAlgorithm (и, возможно, стратегии и шаблона, если это необходимо). Вот что я приготовил:

    class Mapper {
        map(String fileA, String fileB, String fileC) {
            RecordsList a = new RecordsList(fileA);
            RecordsList b = new RecordsList(fileB);
            MatchingRecordsList c = new MatchingRecordsList();

            for(Record rb : b) {
                int highestPerc = -1;
                MatchingRecords matchingRec;

                for(Record ra : a) {
                    int perc;
                    rb.setMatchingAlgorithm(someAlgorithmYouVeDefined);
                    perc = rb.match(ra);
                    if(perc > highestPerc) {
                        matchingRec = new MatchingRecords(rb, ra, perc);
                    }
                }

                if(matchingRec != null) {
                    c.add(matchingRec);
                }
            }

            c.saveToFile(fileC);
        }
    }

    class MatchingAlgorithm {
        int match(Record b, Record a) {
            int result;
            // do your magic
            return result;
        }
    }

    class Record {
        String Id;
        String Name;
        String Address;
        String City;
        String State;
        String Zipcode;

        MatchingAlgorithm alg;

        setMatchingAlgorithm(MatchingAlgorithm alg) {
            this.alg = alg;
        }

        int match(Record r) {
            int result; -- perc of match
            // do the matching by making use of the algorithm
            result = alg.match(this, r);
            return result;
        }

    }

    class RecordsList implements List<Record> {
        RecordsList(file f) {
            //create list by reading from csv-file)
        }
    }

    class MatchingRecords {
        Record a;
        Record b;
        int matchingPerc;

        MatchingRecords(Record a, Record b, int perc) {
            this.a = a;
            this.b = b;
            this.matchingPerc = perc;
        }
    }

    class MatchingRecordsList {
        add(MatchingRecords mr) {
            //add
        }

        saveToFile(file x) {
            //save to file
        }
    }

(Это написано в Notepad++, поэтому могут быть опечатки и т. д. Кроме того, предложенные классы, безусловно, могут выиграть от небольшого рефакторинга, но я оставлю это вам, если вы решите использовать этот макет.)

Как ни странно, я сейчас работаю над проектом почти таким же, как этот.

Простой ответ: хорошо, во-первых, это не конец света, если метод какое-то время находится в неправильном классе! Если все ваши классы покрыты тестами, место, где живут функции, важно, но их можно плавно изменять по своему усмотрению, как вы, король своей области.

Если вы не это тестируете, это будет моим первым предложением. Многие люди, умнее меня, отмечали, как TDD и тестирование могут помочь естественным образом привести ваши классы к лучшему дизайну.

Подробный ответ. Вместо того, чтобы искать шаблоны для применения к дизайну, я предпочитаю думать так: по каким причинам каждый из ваших классов должен измениться? Если вы отделите эти причины друг от друга (в чем вам может помочь TDD), то вы начнете видеть, что шаблоны проектирования естественным образом возникают из вашего кода.

Вот несколько причин для изменения, о которых я мог подумать, прочитав ваш вопрос за несколько проходов:

1. Файл данных изменяет формат/добавляет столбцы
2. Вы найдете лучший алгоритм сопоставления или: «теперь мы хотим фильтровать и по номеру мобильного телефона»
3. Вас также просят сделать так, чтобы он соответствовал файлам xml/yaml/etc.
4. Вас попросят сохранить его в новом формате/местоположении.

Итак, если реализация любого из них заставит вас где-то добавить «оператор if», то, возможно, это шов для подклассов, реализующих общий интерфейс.

Также, допустим, вы хотите сохранить созданный файл в новом месте. Это одна из причин для изменения, и она не должна пересекаться с необходимостью изменения стратегии слияния. Если эти две части принадлежат одному и тому же классу, у этого класса теперь две обязанности, а это нарушает принцип единой ответственности< /а>.

Итак, это очень краткий пример, чтобы углубиться в хороший объектно-ориентированный дизайн, ознакомьтесь с принципы SOLID. Вы не ошибетесь, если изучите их и постараетесь применять их с осторожностью во всех своих объектно-ориентированных проектах.