Код с душком (рефакторинг М. Фаулера)

Небольшая шпаргалка для новичков, и всех остальных кто забыл, по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.

Зачем? Когда и как?

Тут особо углубляться не хочется, т.к. всё зависит от многих факторов: знания, необходимость, сроки, конкретный проект и т.д. и т.п.
Главное чего стоит не забывать и придерживаться, что всё хорошее, полезно в меру.

Код с душком

От чего надо избавляться в процессе рефакторинга и при написании новых программ.

1. Дублирование кода.
2. Длинный метод.
3. Большой класс.
4. Длинный список параметров.
5. Расходящиеся модификации.
   Если при добавлении нового функционала приходится модифицировать несколько методов и значительную часть кода в классе.
6. Стрельба дробью.
   Если при добавлении нового функционала приходится вносить одинаковые изменения в большое число классов.
7. Завистливые функции.
   Метод интересуется больше не тем классом, в котором находится, а другим.
8. Группы данных.
   Похожие группы данных, в разных частях кода.
9. Одержимость элементарными типами.
10. Операторы типа switch.
    Незабываем про ООП.
11. Параллельные иерархии наследования.
    Дублированный код.
12. Ленивый класс.
    Не используемый или остался после рефакторинга.
13. Теоретическая общность.
    Переизбыток абстракциями тоже вреден.
14. Временное поле.
    Если у класса есть переменные, которые используются в одном методе из пяти, то лучше эту переменную передавать в тот самый метод через параметр, а не через конструктор или какой другой способ.
15. Цепочка сообщений.
    Глубокая последовательность вызовов до необходимой информации, через объекты по иерархии классов.
16. Посредник.
    Большую часть методов класс делегирует другому классу.
17. Неуместная близость.
    Классы не должны выставлять наружу закрытые части, т.е. внутреннюю кухню. При наследовании, подклассы должны знать минимум необходимой информации о родителе.
18. Альтернативные классы с разными интерфейсами.
    Дублирование логики.
19. Неполнота библиотечного класса.
    Не бойтесь расширять функционал библиотечных классов: extension методы или декорировать объект библиотечного класса.
20. Классы данных.
    Делите на логические единицы. Доступ на изменение данных должен быть осмысленным.
21. Отказ от наследства.
    Если наследнику нужна лишь малая часть информации (данных, методов) о родителе.
22. Комментарии.
    Свидетельство кода с «запахом», нужно рефакторить. Возможно код остаётся на будущий рефакторинг или описывает сложные манипуляции

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

Какой профит.

Простота в поддержке и понимании кода, а также в написании тестов.

Послесловие

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