Організація даних

Рефакторингі цієї групи покликані полегшити роботу з даними, замінивши роботу з примітивними типами багатими функціональністю класами.

Крім того, важливим моментом є зменшення зв'язаність між класами, що покращує переносимість класів і шанси їх повторного використання.

Самоінкапсуляція поля

Проблема: Ви використовуєте прямий доступ до приватних полів усередині класу.

Рішення: Створіть геттер і сеттер для поля, і користуйтеся для доступу до поля тільки ними.

Заміна простого поля об'єктом

Проблема: В класі (чи групі класів) є поле простого типу. У цього поля є своя поведінка і пов'язані дані.

Рішення: Створіть новий клас, помістіть в нього старе поле і його поведінку, зберігаєте об'єкт цього класу в початковому класі.

Заміна значення посиланням

Проблема: Є багато однакових екземплярів одного класу, які можна замінити одним об'єктом.

Рішення: Перетворіть однакові об'єкти на один об'єкт-посилання.

Заміна посилання значенням

Проблема: У вас є об'єкт-посилання, який занадто маленький і незмінний, щоб виправдати складнощі по управлінню його життєвим циклом.

Рішення: Перетворіть його на об'єкт-значення.

Заміна поля-масиву об'єктом

Проблема: У вас є масив, в якому зберігаються різнотипні дані.

Рішення: Замініть масив об'єктом, який матиме окремі поля для кожного елементу.

Дублювання видимих даних

Проблема: Дані предметної області програми зберігаються в класах, що відповідають за призначений для користувача інтерфейс (GUI).

Рішення: Має сенс виділити дані предметної області в окремі класи і, таким чином, забезпечити зв'язок і синхронізацію між класом предметної області і GUI.

Заміна одностороннього зв'язку двонаправленим

Проблема: У вас є два класи, яким потрібно використовувати фічі один одного, але між ними існує тільки односторонній зв'язок.

Рішення: Додайте бракуючий зв'язок у клас, в якому він відсутній.

Заміна двонаправленого зв'язку одностороннім

Проблема: У вас є двосторонній зв'язок між класами, але один з класів більше не використовує фічі іншого.

Рішення: Приберіть невживаний зв'язок.

Заміна магічного числа символьною константою

Проблема: В коді використовується число, яке несе якийсь певний сенс.

Рішення: Замініть це число константою з такою назвою, що пояснює сенс цього числа.

Інкапсуляція поля

Проблема: У вас є публічне поле.

Рішення: Зробіть поле приватним і створіть для нього методи доступу.

Інкапсуляція колекції

Проблема: Клас містить поле-колекцію, а також простий геттер і сеттер для роботи з цією колекцією.

Рішення: Зробіть значення, що повертає геттер, доступним тільки для читання, а також створіть методи додавання/видалення елементів цієї колекції.

Заміна кодування типу класом

Проблема: У класі є поле, що містить кодування типу. Значення цього типу не використовуються в умовних операторах і не впливають на поведінку програми.

Рішення: Створіть новий клас і застосовуйте його об'єкти замість значень закодованого типу.

Заміна кодування типу підкласами

Проблема: У вас є закодований тип, який безпосередньо впливає на поведінку програми (ґрунтуючись на значеннях цього поля, в умовних операторах виконується різний код).

Рішення: Для кожного значення закодованого типу створіть підкласи. А потім винесіть відповідну поведінку з початкового класу в ці підкласи. Код, що управляє, замініть поліморфізмом.

Заміна кодування типу станом/стратегією

Проблема: У вас є закодований тип, який впливає на поведінку, але ви не можете використати підкласи, щоб позбавитися від нього.

Рішення: Замініть кодування типу об'єктом-станом. При необхідності замінити значення поля з кодуванням типу в нього підставляється інший об'єкт-стан.

Заміна підкласу полями

Проблема: У вас є підкласи, які відрізняються тільки методами, що повертають дані-константи.

Рішення: Замініть методи полями в батьківському класі і видаліть підкласи.

Замучились читати?

Збігайте за подушкою, в нас тут контенту приблизно на 7 годин читання.

Або спробуйте наш новий інтерактивний курс з рефакторингу. Він більш інформативний та набагато цікавіший за банальний тест.

Дізнатися більше...