Подходит к концу очередная неделя курса. Вы узнали много нового в объектно-ориентированном образе мышления и программирования. В течение недели я часто говорю, что написать хороший объектно-ориентированный код — это довольно сложная задача и не все с ней справляются. Представьте ситуацию: Вы устраиваетесь в новую компанию разработчиком, на освободившееся место. И Вам дают код, который необходимо поддерживать и усовершенствовать. Вы открываете файл и от увиденного Вам становится плохо. Данный код — не то, что поддерживать, его и читать-то невозможно. Но Вам с этим еще жить. Поэтому наступает момент, когда начинается рефакторинг кода. Давайте дадим определение, что же такое рефакторинг. Рефакторинг или переработка кода — это процесс преобразования внутренней структуры кода, который призван облегчить его понимание. Понятие рефакторинга иногда путают с понятием оптимизации или реинжиниринга. При оптимизации главной задачей является увеличение производительности некоторого куска кода. При этом понятность этого кода может даже снизиться. При реинжиниринге изменяется не только внутренняя структура программы, но и ее работа. Предпосылками к рефакторингу может быть очень много. Это может быть слишком сложная архитектура, которую необходимо упростить; это может быть использование функций и объектов, затрудняющих понимание работы системы. Когда мы говорили про наследование, мы упоминали, что цепочки наследования также необходимо сворачивать. Это тоже происходит на этапе рефакторинга. Рефакторингом можно также назвать преобразование процедурного кода в объектно-ориентированный. Как же увидеть, что Вашу программу срочно следует рефакторить? В первую очередь, когда Вы чувствуете, что в Вашем коде становится проблематично разобраться, тогда следует его исправлять. Умение улавливать этот момент приходит только с опытом. Однако есть некоторые признаки, которые отличают код, который требует рефакторинга, от того, который не требует. Это так называемый "код с запашком". Что же за запашки есть у кода? Это, во-первых, дублирование кода, длинные методы, большие классы, длинные списки параметров, жадные функции, избыточные временные переменные, классы данных, несгруппированные данные. Давайте разберемся поподробнее. Сам процесс рефакторинга тоже является искусством, требующим практики. Однако методы его следуют напрямую из возникающей проблемы. При дублировании некоторого куска кода, следует выделить этот самый дублирующийся код в отдельный метод. При дублировании кода в разных подклассах одного класса, следует перенести дублирующийся код в базовый. Если общего базового класса нету, то дублирующийся код в разных подклассах следует создать новый базовый класс, в который и перенести этот самый код. Длинные методы очень сложно воспринимать. Если в коде присутствуют длинные методы, их, скорее всего, можно разбить на какие-то логические блоки, которые в дальнейшем выделять в отдельные методы. Если эти блоки связаны какими-то локальными переменными, эти значения переменных можно передавать в качестве аргументов. Под большими классами имеются в виду классы, содержащие слишком большое количество функциональности, ответственности. Это напрямую противоречит SOLID-принципам ООП. И такие классы надо делить на какие-то более мелкие фрагменты. Длинные списки параметров функций затрудняют читаемость Вашего кода и использование этих самых функций. В таком случае следует подумать, откуда берутся эти параметры? Быть может, в Вашем классе есть объект, из которого можно многие из этих параметров напрямую получить? Тогда имеет смысл передавать этот самый объект, а необходимые данные уже получать в процессе работы функции. При этом, не следует скатываться и в другую крайность — это жадные функции. При этом, методы одного класса очень часто обращаются к полям другого класса. Если возникает такая ситуация, следует подумать: не стоит ли перенести те методы, которые являются жадными в другой класс? Следующая проблема — это когда классы держат слишком много кода, который используется только в исключительных случаях. Такой код лучше всего вынести в отдельный класс, а в этих самых исключительных случаях обращаться к объекту того класса. Класс данных — это ситуация, когда классы держат только поля и не содержат методов. Вместо таких классов, скорее всего, следует использовать некоторые объекты-контейнеры, например, словарь. Последний из запашков относится скорее к процедурному коду. У Вас в программе может храниться большое количество переменных и функций, которые эти самые переменные обрабатывают. В таком случае, возможно, имеет смысл взять их все и объединить в один класс. Также, часто имеет смысл переименовывать некоторые переменные для повышения понятности и читаемости кода. Подведем итоги. Необходимость рефакторинга возникает, когда код становится непонятным и сложно поддерживаемым. Умение видеть такие ситуации — это искусство, но существуют некоторые явные признаки, позволяющие понять, что время пришло. Есть некоторые стандартные методы избавления от запашков в коде, но, в общем случае, умение сделать код красивым — тоже является искусством. В этой неделе мы разобрались с тем, что такое объектно-ориентированное программирование. В следующей неделе Вы будете применять полученные навыки для проектирования таких сложных структур, как паттерны проектирования.
