как правильно устранить “запах” кода “Большой класс”?

#ооп #рефакторинг

Помогите пожалуйста разобраться с "запахом кода", который называется Большой класс.
У меня есть класс, в котором создается GUI. На GUI добавляется панель, на которую добавляется
много элементов управления. В общем, все это имеет достаточно сложную структуру.
Вот метод, с которого начинается создание этой панели:

private static JPanel createTasksMainInfoPanel(JTabbedPane taskTabbedPane) {
    JPanel panelForMainInfo = new JPanel();
    //code...
    addComponentForMainInfoBox(verticalBoxForTaskMainInfo, new String(),
            createTypeChoicePanel(max, min));
    JButton ok = new JButton("OK");
    createListenerForOk(ok, fieldForName, fieldForVarQuantity,
            FieldForLimitQuantity, FieldForCritQuantity, max,
            taskTabbedPane);
    addComponentForMainInfoBox(verticalBoxForTaskMainInfo, new String(), ok);
    panelForMainInfo.add(verticalBoxForTaskMainInfo);
    return panelForMainInfo;
}


Здесь я привел только начало и конец метода. В середине еще строк 50. Плюс в конце
у меня идут вызовы других методов, которые так же нужны что бы создать эту панель.
В них приходится передавать кучу параметров. В общем, в результате я имею длинные методы
с большим списком параметров. И мой класс, где создается GUI разрастается до огромных
размеров. Не лучше ли мне выделить для создания этой панели отдельный класс? Тогда
все что я передавал в параметрах можно было бы сделать полями этого класса. И можно
было бы выделить более компактные методы и без огромных списков параметров. Или может
я вообще зря это затеял. Ведь добавится еще один класс, а значит новые связи между
классами. К тому же, не противоречит ли это принципу единственной обязанности(single
responsibility principle)? Ведь эта панель входит в GUI, то есть ее отрисовка входит
в обязанность этого класса GUI?
    

Ответы

Ответ 1

Под "большим классом" Фаулер понимает не размер в строках, а размер функциональности.
То есть когда в классе много разнородных ответсвенностей класс считается "большим".
Следовательно чтобы назвать класс "большим" надо составить перечень его ответсвенностей
и определить насколько они разнородные.

В вашем случае функция класса состоит в сопоставлении визуальной структуры гуя и
внутренней структуры гуя. Поэтому на нем лежит две ответсвенности: знать визуальную
структуру и знать внутреннюю структуру. 

Визуальная структура гуя это то, что мы видим на экране: кнопка внутри панельки,
панелька на форме, форма слева на окне, нажатие на кнопку выводит диалог, и так далее.
Тут все понятно. 

Внутренняя структура гуя это то, как связаны объекты контролов между собой: кто кого
содрежит, кто кому сообщения посылает, как контролы создаются и настриваются, и прочее.
Но к внутренней структуре гуя (именно гуя) не относится то как объекты контролов связаны
с другими объектами неконтролами! Это другая ответсвенность.

Судя по коду, который вы привели, у вас ничего такого не наблюдается, поэтому ваш
класс нельзя назвать "большим". Если вас смущает его размер посмотрите на это с другой
стороны. Сейчас у вас одно место где весь гуй создается и настривается, то есть когда
вы хотите что-то поменять на форме вам не надо вспоминать в какой файл смотреть - это
один и тот же файл. Если вы разнесете эту логику по 10 классам, то у вас будет 10 мест
для поиска.