в двух подклассах есть одинаковые поля - переместите поле в родительский класс (та же рекомендация про методы и конструкторы с одинаковым функционалом)

в родительском классе есть методы(поля) относяшиеся только к некоторым из его подклассов - переместить в эти подклассы. Подкласс должен ВСЕГДА следовать интерфейсу родительского класса.

классе есть функционал который используется в редких случаях - создайте класс для этого подмножества функций

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

родительский класс и подкласс мало отличаются - объедените их в один

подкласс использует только часть интерфейса родительского класса - убрать наследование, сделать отдельным классом, а класс бывшего родителя передавать в конструктор(это к примеру, тут есть варианты) потому что Подкласс должен ВСЕГДА следовать интерфейсу родительского класса.

Не следует в метод передовать большое кол-во параметров. Т.к. такой код трудно читать и модифицировать. Как вариант передавать объект или массив данных. Также неплохой вариант передавать несколько массивов с данными разделенными на группы.

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

Также не нужно передавать в метод лишних параметров. Наприме те параметры, которые можно легко "вычислить" внутри метода.

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

Если есть метод, который берет некие данные, а так же изменяет их, то нужно его разделить на 2 метода. Один  берет данные, второй изменяет

Рефакторинг может замедлить действие программы. Из этой ситуации есть следующий выход.

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

Итак, после того как код хорошо структурирован, программа  запускается через профайлер. Обычно нужно оптимизировать несколько узких мест и все. Не более 90% кода обычно. Не нужно гадать, нужно точно знать где узкие места, поэтому запуск через профайлер обязателен.

Код с душком:

1. Дублирование кода

2. Длинный метод

 - если ощущается необходимость что-то прокомментировать, нужно этот код выносить в отдельный метод

- даже одну строку нужно выделять в метод, если она нуждается в разъяснениях

Несколько слов об оптимизации, о поиске узких мест. Даже если вы отлично знаете как работает система, не гадайте на кофейной гуще, а производите замеры. В 9 случаях, из 10 полученная информация покажет, что вы ошибались.

Рефакторинг не следует оставлять на потом. Им следует заниматься понемногу и постепенно.

Небольшое изменение, тестирование, небольшое изменение, тестирование, небольшое изменение, тестирование. Именно такой должен быть ритм рефакторинга, чтобы он был быстрым и безопасным

В большинстве случаев, метод должен принадлежать объекту, данные которого он использует.

Временные переменные не есть гуд в длинных методах. От них нужно избавляться дублированием метода результат которого присвоен временной переменной. Да, да за счет снижения производительности. (стр 37)

При рефакторинге лучше двигаться маленькими шагами