Какой шаблон проектирования использовать для одного большого метода, вызывающего множество частных методов - PullRequest
Новая
       7

Какой шаблон проектирования использовать для одного большого метода, вызывающего множество частных методов

3 голосов
/ 12 июня 2010

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

Вот пример кода: 

public void handleRow(Object arg0) {
    if (continueRunning){
        hashData=(HashMap<String, Object>)arg0;
        Long stdReportId = null;
        Date effDate=null;
        if (stdReportIds!=null){
            stdReportId = stdReportIds[index];
        }   
        if (effDates!=null){
            effDate = effDates[index];
        }
        initAndPutPriceBrackets(hashData, stdReportId, effDate);
        putBrand(hashData,stdReportId,formHandlerFor==0?true:useLiveForFirst);
        putMultiLangDescriptions(hashData,stdReportId);
        index++;
        if (stdReportIds!=null && stdReportIds[0].equals(stdReportIds[1])){
            continueRunning=false;
        }       
        if (formHandlerFor==REPORTS){
            putBeginDate(hashData,effDate,custId);
        }
        //handle logic that is related to pricemaps.
        lstOfData.add(hashData);
    }
}

Какой шаблон проектирования я должен применить к этой проблеме?

Ответы [ 4 ]

2 голосов
/ 12 июня 2010

Шаблон состояния довольно хорошо описывает этот сценарий.

Подробности здесь

Вот пример C #

Наслаждайтесь!

1 голос
/ 12 июня 2010

Я бы просто связывал связанные методы и состояния (поля) в классы с открытыми методами и вставлял их как сервисы в хост-класс.

Шаблон состояния , как и Дуг, описал такое разделение.

Также обязательно избегайте циклических зависимостей при разделении поведения. Это может легко произойти, если сделать это поспешно.

Как правило, разделить поведение классов на несколько классов для повторного использования и настройки. Если единственная цель - улучшить тестируемость, то проще выставить методы защищенными или общедоступными.

0 голосов
/ 12 июня 2010

Драматический рефакторинг, который вы описываете исключительно для того, чтобы соответствовать вашим инструментам модульного тестирования - это действительно очень плохая идея.

Не позволяйте недостаткам инструментов управлять вашим дизайном.

0 голосов
/ 12 июня 2010

Ваше беспокойство по поводу модульного тестирования можно решить, сделав методы «защищенными» и поместив тестовые классы в тот же пакет, что и исходный код.

...