Харесвам рефакторинг. Не, не така. Обичам преработването. Не, дори и това. аз по дяволитеОбичам преработването.
Не понасям лош код и лоша архитектура. Настръхвам, когато пиша нова функция, а следващият курс е пълна бъркотия. Просто не мога да гледам тъжно наречените променливи. Понякога, преди да си легна, затварям очи и си представям какво може да се подобри в даден проект. Понякога се събуждам в три през нощта и отивам до лаптопа си, за да оправя нещо. Искам кодът да не е просто код на който и да е етап от разработката, а произведение на изкуството, което е приятно за гледане и приятно за работа.

Ако дори малко споделяш чувствата ми, значи имаме за какво да говорим. Факт е, че с времето нещо вътре в мен започна да ми казва, че преработването на всичко, навсякъде и през цялото време не е най-добрата идея. Не ме разбирайте погрешно, кодът трябва да е добър (и би било по-добре, ако беше перфектен), но в суровата реалност не винаги е разумно постоянно да подобрявате кода. Измислих няколко правила за себе си относно навременността на преработването. Ако започна да ме сърби да подобря нещо, тогава поглеждам назад към тези правила и започвам да си мисля: „Сега ли е наистина моментът, в който трябва да преработим?“ Нека помислим в какви случаи рефакторингът е подходящ и в кои не е толкова много.

Отказ от отговорност.Най-вероятно, след като прочетат публикацията, мнозина ще искат веднага да кажат: „Да, това вече е обсъждано 600 пъти!“ или „Това е толкова очевидно, защо да пиша за това?“ Може да сте прави, но ето какво е: в света около нас все още цари хаос. Изглежда, че всичко е ясно на всички, но в действителност се оказва, че не е толкова ясно. Затова мисля, че няма да е много вредно да хвърлим още един поглед на тази тема. Но ако конкретно нямате никакви проблеми с преработването, тогава можете просто да пропуснете тази публикация, вече сте добре.

Преработете твърде рано

Можете ли да си спомните последния път, когато сте имали постоянна декларация за работа, която не се е променяла с месеци? Не съм много добър в запомнянето на това. Живеем в реалния свят, изискванията се променят през цялото време. Освен това, това не е задължително да са външни изисквания - това могат да бъдат вашите собствени изисквания към проекта. Нека обясня идеята с пример: да кажем, че сте се заели със средно голям проблем за един или два дни. Първите няколко класа вече са написани, но все още няма нищо за стартиране - процесът на писане на суровата архитектурна част е в ход. И тогава забелязвате, че една от частите на проекта не е написана по особено универсален начин: „Но ако след шест месеца трябва да направите X, тогава всички ще страдат.“ Логично е, че не бихте искали да изпратите глупав код в хранилището и другите разработчици да ви мислят за лошо име. И започвате да преработвате все още не е готова функция. Понякога това е оправдано, но на такава пътека трябва да има знак "ОПАСНО". Така че оправяте едно нещо, после друго, после трето. Измина седмица, функцията все още не се стартира и вие казвате: „Някак си всичко беше направено погрешно. Но сега аз разбрах точнокак да го направя. Сега бързо ще пренапиша всичко от нулата. Основният проблем е, че обратната връзка за функцията все още не е получена и вие вече сте започнали да работите по подобряване на кодовата база. Този подход рядко води до успех. Не знам за вас, но често ми се случва, че след внедряване на функция започвам да разбирам, че всичко трябва да работи малко по-различно. И не защото съм толкова глупав и не можах да го обмисля добре предварително. Просто трябва да „докоснете“ някои функции, за да разберете как трябва да бъде всичко в изданието. Понякога имате нужда от малък прототип (дори с скапан код и грешки), за да обсъдите функция с колеги. Понякога трябва да покажете нещо на клиента, за да може той да каже: „Не, добре, не исках това, всичко трябва да е обратното.“ Понякога потребителите не харесват иновациите; искат всичко както е било. Проблемът с новите функции е, че е трудно да се предвиди съдбата им. Често се случва всички разработки да бъдат изхвърлени в кошчето, защото след обсъждане на първата версия екипът реши да направи всичко по различен начин. Общо заключение: не трябва да преработвате кода твърде рано, особено ако не сте сигурни, че този код ще остане 100% в проекта.

Нецелеви рефакторинг

Най-вероятно имате план за развитие за близко бъдеще. Вероятно имате крайни срокове (дори и сами да ги поставите). Изданията трябва да се извършват навреме; разработката не трябва да се забавя. Трябва да се контролирате, трябва да правите онези неща, които са част от непосредствените ви цели. Да приемем, че имате част от кода, който изглежда завършен... Е, изглежда зле. Но нека продължим предположението си, че сега не работите с него. Тази лоша част от кода е стабилна, върши работата си успешно и няма нищо общо с текущата ви задача. Е, не го докосвайте! Да, може да сте изключително натъжени от факта, че в другия край на проекта всичко е много лошо. Но забележете, че в момента това не ви притеснява по никакъв начин. Имате текущи задачи, справяйте се с тях. Разбира се, има задачи за подобряване на кодовата база, но не често - често е по-важно да добавите нова функционалност или да коригирате грешки. Концентрирайте се върху поставените задачи и не се отказвайте от тях, защото някъде нещо не е наред.

Рефакторинг в името на рефакторинга

Добре, стигнахте до заключението, че определено трябва да преработите част от проекта. Добре, нека преработим. Изглежда, че планираните подобрения са завършени, но тогава възниква мисълта: „Какво друго мога да подобря? Да, това нещо там. И след това нещо ще се появи това нещо, а след това друго, след това друго и т.н. Трябва да разберете, че има лош код, има добър код, има идеален код. Никога няма да имате последното в голям проект. Това не означава, че не трябва да се стремите към него, но трябва да разберете, че е непостижимо. Обикновено целта е да напишете добър код, а не перфектен код. Да кажем, че след рефакторинг имате напълно четим код, който работи по повече или по-малко очевиден начин, в който няма патерици и който не е толкова труден за използване. Задайте си въпроса: „Може би е време да спрете?“ Да, кодът може да бъде подобрен. Нещо повече, в достатъчно голям проект може да се подобрява безкрайно. Но в момента той се справя с функциите си, удобен е за използване и практически не ви причинява дискомфорт. Много е важно да определите сами приемливокачеството на кода, след което спирате да го подобрявате (докато не се загуби свойството за приемливост). Не забравяйте, че все още има толкова много различни готини неща, които можете да добавите. Няма нужда да се рефакторира в името на самия рефакторинг, в името на перфектния код. Трябва да преработите, когато имате завладяващпричини за това: кодът е труден за четене, кодът е труден за поддръжка, кодът е труден за разработване, кодът е труден за използване и т.н. Ако не възникнат „трудности“, тогава завладяващНяма причина да губите време за рефакторинг.

Рефакторинг в деня преди пускането

Случва се освобождаването да е вдругиден/утре/днес/трябва да е вчера (подчертайте, ако е необходимо). Това е важен момент от живота на проекта. Необходимо е да се обърне специално внимание на тестването, коригирането на критични грешки и окончателните подобрения. Повярвайте ми, наистина е лоша идея да преработите кодовата база (и дори по-лошо, да я преработите добре) в момента, когато трябва да изпратите проекта в производство. Опитната практика предполага, че трябва да го освободите и след това спокойно да подобрите кода с чиста съвест. Някои ще попитат: "Защо?" Ако този въпрос е възникнал, вероятно все още не ви се е налагало да правите сложен рефакторинг. Ще ви подскажа: когато пренапишете кода, той не винаги се подобрява непременно - понякога може да се повреди. Какъв сложен рефакторинг има - понякога коригирате един метод с пет реда, не успявате да следите някаква зависимост, а в другия край на проекта се прокрадва грешка, която любимите ви потребители веднага ще срещнат. Изглежда, че не правите нищо лошо, а след това изведнъж звярът „Не беше очевидно“ ви напада и ви удавя в езерце с фалшива първоначална оценка. Въпреки че може би просто съм толкова лош програмист - обичам да разбивам неща. Напълно възможно е винаги да преработвате всичко абсолютно правилно и с пълен контрол върху целия проект. В този случай мога да ви поздравя, но все пак няма да откажа съвета да забраня предварителното рефакторинг. Повярвайте ми, рефакторингът няма да изчезне за няколко дни и целият екип ще спи малко по-спокойно.

Рефакторинг на много стар код

Въпросът е труден, много труден. Ситуация: има огромен брой ужасни редове код, които сте наследили от стари разработчици (може би тези стари разработчици сте били вие преди няколко години, дори преди да сте се научили да пишете всичко правилно и наведнъж). Кодът трябва да се поддържа. Тук-там възникват патерици и дублации, ентропията расте. Всеки ден искам все повече и повече да изхвърля всичко и да го пренапиша от нулата. В такъв момент се налага много добрепомислете за рисковете. Да, вероятно подобни дейности ще бъдат полезни в бъдеще. Но в каква гледна точка точно и колко полезен? Най-вероятно в процеса на голям рефакторинг или пренаписване на отделни части ще замените стария работен код с нов, перфектно написан код, но с грешки. И съвсем не защото си лош програмист и пишеш лошо. Може просто да не знаете този код достатъчно. Може да не знаете защо авторът е написал всичко по този начин, но може да има причини. Понякога трябва да пишете много странен и крив код. Мога да измисля много примери: потискане на трудни оптимизации на процесора, коригиране на бъгове в библиотека на трета страна, потискане на някои многонишкови задръствания и т.н. Не казвам, че всички тези проблеми не могат да бъдат разрешени нормално. Просто понякога при пренаписване на привидно абсурден код в нормален код се появяват грешки. Да, беше възможно да направите всичко нормално, но може просто да не осъзнаете величието на колиба, направена от патерици вместо пръчки, ако не разберете от автора на кода защо го е написал по този начин (и такава възможност не винаги се предоставя). Бъдете внимателни, когато пренаписвате стар код, който не разбирате напълно (и особено ако смятате, че няма какво да разбирате).

Кога трябва да преработите?

Извинявам се, ако тази статия ви създава впечатлението, че рефакторингът не е нищо друго освен проблеми. Все още настоявам, че кодът трябва да бъде четим и красив, трябва да е лесен за използване и да бъде лесен за разработване. Положителният подход е по-добър от отрицателния, така че третирайте рефакторинга не като източник на проблеми, а като много добър приятел, който ще ви помогне в трудни моменти. Освен това този приятел може да се погрижи да има по-малко трудни моменти във вашето светло бъдеще. В заключение бих искал да подчертая няколко точки, когато рефакторингът е наистина подходящ.

• нищо за правенеИма тихи периоди на престой, когато всички важни задачи са затворени и нови все още не са възложени. Е, не че няма абсолютно нищо за правене, но има известно количество свободно време. Похарчете го за подобряване на вашия код. Дайте ясни имена на обектите, отървете се от дублирането, пренапишете лоша част от архитектурата. Въпреки че не се добавя нова функционалност, вие допринасяте за спокойствието на разработчиците, които ще продължат проекта. Повярвайте ми, това е важно.
• Ежедневно страдание.И се случва да има парче от проект, което те кара да въздишаш тежко всеки ден. А от съседните маси се чуват тежките въздишки на колегите. Разбира се, въпреки че излизането не е утре, все още има достатъчно важни задачи. Въпреки това минава седмица след седмица и гледането на тази част от проекта става все по-тъжно. Кажете си: „Спри да търпиш това!“ Ако бизнес планът е написан от вашия шеф, обяснете му, че този код просто трябва да бъде пренаписан. Ако работите за клиент, убедете го, че една седмица, прекарана в рефакторинг, ще спести много време за разработка в бъдеще. Ако работите за потребители, тогава решете, че би било по-добре за тези потребители да изчакат още седмица за изданието този път, но след това да се насладят на стабилен софтуер и редовни актуализации. Да, не винаги е лесно да постигнете съгласие с всички и със себе си, но опитайте.
• Проблемът с късния рефакторинг.Правилото за твърде ранен рефакторинг не трябва да се абсолютизира. Някои хора мислят така: „Сега подобрявам нещо, но няма да е полезно - ще бъде жалко.“ Трябва да разберете, че може да има важни части в ядрото на програмата, които би било по-добре да бъдат написани добре. Не забравяйте, че колкото по-късно преработвате, толкова по-висока е цената, защото ще отделите повече време и усилия за пренаписване. Критичните основи (тези, използвани в целия проект) трябва да бъдат във възможно най-добрата форма по всяко време. Ще бъде просто страхотно, ако дипломната работа работи във вашия екип „Рефакторингът не закъсня. Той идва стриктно, когато намери за добре..
• Среща с чудовище.Започвате да изрязвате нова функционалност, която трябва да използва стара част от проекта, която изглежда като истинско чудовище: започвате да се плашите, когато погледнете външния интерфейс. Ако времето позволява, първо поправете основната част от кода, така че след това да можете да се съсредоточите върху новата функционалност и да не се разсейвате с набиване на патерици в името на повторното използване на кода.
• Интелигентен перфекционизъм.Забелязали сте лош код? Искаш ли да го поправиш? Наистина ли искате да го поправите? Е, ако наистина искате, тогава можете. Но забележете думата „разумно“. Балансирайте времето, прекарано в рефакторинг, спрямо ползата от подобряването на кода. Не пропускайте крайните срокове и не се затъвайте в безкрайни подобрения. Въпреки това, ако рефакторирате своевременно и умерено, проектът само ще се подобри.

Вместо заключение

Всичко по-горе е чисто субективно обобщение на опита от работата по редица проекти. Разбира се, не съм обхванал всички житейски ситуации. Всеки екип има свои собствени изисквания за код, собствен бизнес план и свои собствени правила. Сигурен съм, че много хора имат пет истории от поредицата „Но имах случай, когато всички тези съвети не проработиха“. Това е абсолютно нормално, както и трябва да бъде. Няма универсален сребърен куршум за определяне на количеството усилия за подобряване на кода („Ще преработваме всеки ден за 47 минути 23 секунди и всичко ще бъде наред“). Трябва, въз основа на собствения си опит във вашия конкретен проект, във вашия конкретен екип, да се опитате да намерите средно положение между писането на нов код и подобряването на стария. Аз само се застъпвам за рационално отношение към всичко без фанатизъм („Защо да подобряваме кода, от това няма да се появи нова функционалност“ / „Спешно трябва да направим целия код перфектен, за да можем по-късно да работим с него нормално“). Бъдете умни в разпределянето на времето си за работа върху съществуващ код и ще се оправите.

Всякакви допълнителни мисли за това кога трябва или не трябва да преработвате са добре дошли. Едно от най-ценните неща в тази област е опитът на реални разработчици по реални проекти.

РефакторингКодирането е процес на промяна на изходния код на програма, без да се засяга нейното поведение и има за цел да я направи по-лесна за разбиране и/или да опрости по-нататъшната й поддръжка. Обикновено рефакторингът на всяка програма включва извършване на малки промени в нейния код, всяка от които не променя поведението на самата програма, но по някакъв начин опростява и/или подобрява кода. В същото време е много важно рефакторингът да се извършва на малки части, т.к когато програмистът промени малка част от кода, за него е много по-лесно да следи правилността на промените и да не прави грешки. Ако преработвате големи части от код наведнъж, тогава има много голяма вероятност да направите грешки, в резултат на което програмата може да спре да работи напълно. Вярно е, че фактът, че редакциите трябва да са малки, не означава, че рефакторингът е просто замяна на имена на променливи или преместване на малки части от код от едно място в програмата на друго - рефакторингът ви позволява напълно да преработите цялата програма, включително логиката на нейната поведение, основното е - правете промени в малки части и тогава всичко ще бъде наред.

Рефакторинг на целите

Сигурно ще ме попитате защо все пак пиша това? И до точката, че ако внимателно разгледате изходния код, например изходните текстове за всеки урок, вероятно сте забелязали, че често променям нещо в кода, понякога по малък начин, а понякога доста забележимо. Това е защото Аз самият използвам рефакторинги искам това да стане навик и за вас.

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

Какъв код трябва да бъде преработен

Можете и често трябва да преработите всеки код - най-често просто трябва да разчитате на инстинктите си, ако някой код не ви се струва много успешен или ви се струва, че след седмица вече ще забравите какво представлява този или онзи раздел на код прави - най-вероятно този код се нуждае от преработване. Ще се опитам да формулирам основните правила, въз основа на които можете да разберете, че вашият код изисква преработка:

Ако вашата програма има дублиране на код, тогава почти сигурно е необходим рефакторинг. Дублираният код в програмата е основният източник на грешки.

Ако във вашата програма се изпълнява някакво действие на няколко различни места, но с един и същ код, просто поставете този код в отделна функция и я извикайте. В противен случай има голяма вероятност един ден да редактирате изходния код на едно място, но да забравите да коригирате подобен код на друго и да възникнат грешки.

Дълъг списък с параметри на функция/метод/конструктор.

Големият брой параметри обикновено не само затруднява разбирането какво прави даден метод или функция, но и затруднява разбирането на кода, който използва тези функции. Ако наистина се нуждаете от функция, която да приема много параметри, просто поставете тези параметри в отделна структура (или клас), като дадете на тази структура разумно и разбираемо име и предайте на функцията връзка (или указател) към обект от това структура или клас.

Големите класове също изискват рефакторинг.

Ако имате един или няколко големи (повече от няколко дузини редове код) класове във вашата програма, трябва незабавно да ги разделите на по-малки и да включите обекти от тези класове в един общ клас. Причината за това е същата като в предишния параграф.

Твърде много временни променливи също са знак за лош код, който се нуждае от преработване. По правило много временни променливи се намират в прекалено „раздути“ функции - когато преработвате такива функции, най-вероятно броят на временните променливи във всяка от тях ще стане по-малък и кодът ще стане много по-ясен и удобен

Има много „разхвърляни“ съхранени данни, които са логически свързани и могат да бъдат комбинирани в структура или клас. Логически свързаните данни винаги трябва да се съхраняват в структури/класове, дори и да са само 2-3 променливи - това няма да влоши положението на никого, но кодът ще стане много по-ясен.

Ако обекти от един клас имат достъп (препращат към) данни на друг обект твърде много/често, трябва да преразгледате функционалността на обектите. Може би сте взели грешно архитектурно решение и трябва да го промените възможно най-скоро, преди тази грешка да се разпространи в целия код.

Опитайте се да не съхранявате твърде много глобални променливи. Ако наистина имате нужда от точно толкова много и не по-малко глобални обекти - опитайте поне да ги групирате в структури/класове или поне просто да ги поставите в отделно пространство от имена - тогава има шанс случайно да използвате някоя променлива по грешка, ще стават значително по-ниски.Рефакторинг на код

Цел на работата

1. : научете се да реорганизирате програмния код въз основа на шаблони за рефакторинг.
2. Напредък в работата
3. Използвайки шаблони за рефакторинг, реорганизирайте програмния код на софтуера, който се разработва и модулни тестове.
4. Проверете дали всички модулни тестове се изпълняват успешно.
5. Попълнете описание на извършените операции по преработване (моделът was-was-refactoring).
6. Ако е необходимо, коригирайте проектната документация (диаграми на класове, диаграми на последователности).
7. Направете заключения въз основа на резултатите от работата.

Изисквания към съдържанието на работата

1. Заглавие на произведението.
2. Цел на работата.
3. Кратка формулировка на индивидуалната задача.
4. Таблица с промени в дизайна на софтуера.
5. Коригирани диаграми на класове и последователности, ако е необходимо.
6. Изводи.

Теоретична информация

Признаци на лошо организиран код

Това не е набор от ясни правила, а описание на местата, на които да обърнете внимание при рефакторинг.

Дублиран код

Ако видите едни и същи кодови структури на няколко места, тогава можете да сте сигурни, че тази програма ще бъде по-добра, ако можете да ги обедините.

В най-простите случаи методът за извличане ще ви помогне. Когато работите с наследяване, използвайте Pull Up Field. Ако кодът е подобен, но не точно, трябва да използвате метода за извличане и след това метода за шаблон на формуляр. Ако методите правят едно и също нещо по различни начини, изберете един от тях и използвайте алгоритъм за заместване. Ако имате дублиран код в несвързани класове, помислете за функцията за извличане на клас.

Дълъг метод

Сред обектните програми програмите с кратки методи живеят най-дълго. Колкото по-дълга е процедурата, толкова по-трудна е за разбиране. Ако имате добро име за метода, тогава не е нужно да гледате тялото му.

Следваме евристика: всеки път, когато почувстваме, че трябва да напишем коментар, вместо това пишем метод. В 99% от случаите, за да съкратите метода, ще трябва да използвате само метода Extract. Локалните променливи и параметри могат да ви попречат, така че може да се наложи да замените Temp със заявка, да въведете параметърен обект и да запазите целия обект.

Освен коментарите, циклите и условията също са добри признаци. Използвайте Decompose Conditional за условия, а за цикли поставете тялото на цикъла в отделен метод.

Голям клас

Когато един клас прави твърде много неща, той обикновено има твърде много полета.

Можете да използвате Extract Class или Extract Subclass, за да извлечете някои променливи. Когато определяте какво да извадите, потърсете сходство в имената на променливите, както и дали класът ги използва всичките едновременно.

Освен това, класна стая с твърде много код също е благодатна среда за дублиране и хаос. Тук също използвайте Extract Class или Extract Subclass.

Ако вашият голям клас е GUI клас, опитайте се да отделите поведението от данните. Може да се нуждаете от дублиращи се наблюдавани данни.

Дълъг списък с опции

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

Използвайте Replace Parameter with Method, Preserve Whole Object и Introduce Parameter Object.

Дивергентна промяна

Различна промяна е, когато един клас е обект на различни промени.

Ние структурираме нашия софтуер, за да го направим по-лесен за промяна. Ако искаме да променим нещо, ние търсим единственото място, където можем да направим промяната. Ако не можем да направим това, миришем лошо. Можете да погледнете класа и да си помислите: „Променям тези три метода всеки път, когато свързвам нова база данни, и тези четири - когато добавям финансов инструмент.“ За да подредите това, намерете всичко, което се променя в този конкретен случай, и използвайте Extract Class.

Хирургия с пушка

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

Използвайте Move Method и Move Field, за да поставите всички промени в един клас. Ако нито един клас не изглежда като добър кандидат, създайте нов клас.

Използвайте Inline Class, ако е необходимо. Различна промяна е, когато един клас е засегнат от различни промени, докато операцията с пушка е, когато една промяна засяга множество класове.

Завист по функция

Целта на наличието на обекти в програма е да се комбинират данни и методи, които ги използват. Типична лоша миризма е, когато даден метод изглежда по-заинтересован от данните на друг обект, отколкото от своите собствени.

Просто използвайте метода Преместване, за да го преместите там, където трябва да бъде. Ако само част от метода страда от завист, първо използвайте метода за извличане.

В случай, че даден метод използва данни от множество обекти, поставете го върху обекта, който го интересува най-много. Използвайте метода на извличане, за да изолирате зависимостите.

Използването на някои сложни модели, като Strategy и Visitor, нарушава тези правила. Общата препоръка е винаги да се намира баланс между сложността и необходимата гъвкавост.

Групи данни

Ако видите, че елементите с данни винаги пътуват заедно, комбинирайте ги в един обект. Използвайте Extract Class за полета, Preserve Whole Object и Introduce Parameter Object за параметри на метода.

Един добър метод за тестване е: ако премахнете един от елементите на данните, останалите ще продължат ли да имат смисъл? Ако да, тогава тук трябва да се роди обект.

Обсебеност от примитиви

Начинаещите обектни програмисти обикновено избягват използването на малки обекти за малки задачи като валути, диапазони, специални низове за телефонни номера и други подобни. Можете да излезете от пещерите в цивилизования свят на обекти, като използвате Replace Data Value with Object, Replace Array with Object, ако това е код на тип, използвайте Replace Type Code с Class, Replace Type Code with Sublasses и Replace Type Code with Strategy .

Изявление за превключване (Case).

Добрият обектен код много рядко използва оператори Switch. Често ще видите един и същ Switch на различни места. Ако трябва да добавите друга селекция, ще трябва да потърсите всички оператори Switch.

В повечето от тези случаи лечението е полиморфизъм. Ако Switch превключва по код на тип, използвайте Replace Type Code with Sublasses или Replace Type Code with Strategy. Може да се нуждаете от метод за извличане и метод за преместване, за да изолирате превключвателя и да го поставите в желания клас. След като настроите структурата на наследяване, използвайте Replace Conditional with Polymorphism.

Паралелни йерархии на наследяване

Паралелните йерархии са специален случай на хирургия с пушка. Всеки път, когато добавите дете от клас, вие сте принудени да добавите дете от друг клас. Първо, накарайте екземплярите на една йерархия да се отнасят към съответните екземпляри на друга. След това използвайте Move Method и Move Field и втората йерархия ще изчезне малко по малко.

Мързелив клас

Всеки клас, който създадете, ви струва пари за разбиране и поддръжка. Класа, която не прави достатъчно, за да плати за себе си, трябва да бъде унищожена. Често това е клас, който преди е бил печеливш, но е бил отрязан по време на рефакторинг. Ако е дете на друг клас, използвайте Свиване на йерархията. Почти безполезните класове трябва да преминат през Inline Class.

Спекулативно обобщение

Такъв е случаят, когато някой казва: „О, вижте, ще имаме нужда от тази функция някой ден“ и така иска да вмъкне всякакви кукички и специални случаи, за да се справи с неща, които не са необходими. Резултатът е по-труден за използване и поддръжка.

Ако имате абстрактни класове, които не правят нищо, използвайте Collapse Hierarchy. Ненужното делегиране може да бъде премахнато с помощта на Inline Class. Методите с неизползвани параметри трябва да подлежат на премахване на параметър.

Временно поле

Понякога ще видите код, който използва променливи на екземпляр само в определени случаи. Това го прави много трудно за разбиране.

Използвайте Extract Class, за да направите дом за бедни сираци. Поставете там целия код, свързан с тези полета. Можете също така да се отървете от условния код, като използвате Introduce Null Object, за да създадете алтернативен обект, когато тези полета нямат смисъл.

Нишка за съобщения

Ако видите код, в който клиент иска обект от друг обект, тогава този обект има следващия обект и т.н. Това може да бъде дълъг низ от методи getThis или последователност от временни променливи. Във всеки случай, с такива извиквания, ние изрично предполагаме знания за структурата на обектите във веригата. Всяка промяна в отношенията ще доведе до промяна на този код. Тук трябва да използвате Hide Delegate. Вижте защо се използва резултатът от обаждането. Използвайте метода за извличане и след това метода за преместване, за да го преместите по-нагоре по веригата. Някои са против всяка верига от методи. Ние сме за умереност.

Посредник

Едно от основните свойства на обектите е капсулирането. Питате директора дали е свободен за среща. Той делегира съобщението на своя плановик и отговаря. Не е нужно да знаете дали той използва планер, електронно устройство или секретарка.

Това обаче може да отиде твърде далеч. Поглеждате интерфейса на клас и виждате, че половината от неговите методи просто делегират извиквания към други класове. Време е да използвате Remove Middle Man и да говорите директно с обектите, които знаят какво се случва. Ако само някои методи делегират, тогава стартирайте вградения метод върху тях. Ако добавяте поведение в допълнение към делегирането, използвайте Замяна на делегирането с наследяване.

Неоправдана интимност

Понякога класовете се сближават твърде много и прекарват твърде много време един в друг.

Използвайте Move Method и Move Field, за да разделите части и да намалите близостта. Вижте дали можете да организирате Промяна на двупосочна асоциация на еднопосочна. Ако класовете наистина имат общ интерес, използвайте Extract Class, за да поставите общите части на едно място.

Наследството често води до ненужна интимност. Потомците винаги знаят повече за своите предци, отколкото техните предци биха искали. Използвайте Replace Inheritance with Delegation, когато е време да напуснете дома.

Непълен библиотечен клас

Често не сме напълно доволни от библиотечен клас, но не можем да приложим към него нещо като Move Method. Ако трябва да добавите няколко метода, използвайте Introduce Foreign Method. Ако трябва да добавите много, ще ви е необходимо въвеждане на локално разширение.

Клас данни

Има класове, които съдържат само полета и методи за достъп до тях. Това са просто тъпи контейнери за данни и най-вероятно други класове ги манипулират твърде много в детайли. Първо, приложете Encapsulate Field и Encapsulate Collection, докато никой не гледа. Вижте къде се използват данните от класа. Опитайте да използвате метода Move, за да преместите този код в самия клас данни. Класовете данни са като децата. Те са необходими в началните етапи. Но за да се държат като възрастен обект, те трябва да поемат отговорност.

Отхвърлено наследство

Подкласовете наследяват методи и данни от своите предци. Но понякога не се възползват от това, което им се дава.

Традиционният отговор е, че йерархията е лоша. Трябва да създадете нов производен клас и да приложите Push Down Method и Push Down Field. Но можете да познаете от нашата саркастична употреба на думата традиционен, че не винаги ще го препоръчваме. Ние използваме наследяване за повторна употреба. Придружава се от лоша миризма, но обикновено не е много силна. Ако отхвърленото наследство е проблем, използвайте традиционните съвети.

Mozilla FireFox, за да изясните версията на този софтуерен продукт, трябва да разгънете секцията „Помощ“ в менюто и да щракнете върху най-долния елемент („За Mozilla Firefox“). Ще се отвори отделен вертикален прозорец, в който под големия надпис Firefox се поставя индикация за точния вариант на три числа, разделени с точка.

В менюто на Opera също трябва да отворите секцията „Помощ“ и да кликнете върху долния елемент („За програмата“). Но тук, за разлика от всички други браузъри, не се появява отделен прозорец - отваря се обикновен прозорец, по-голямата част от който е заета от списъци с различни видове хранилища, създадени от браузъра във вашия. В самото начало на този списък има отделен раздел, който се нарича „Информация за версията“. Номерата на версията на Opera са две числа, разделени с точка.

В Internet Explorer, като отворите същата секция на менюто, наречена „Помощ“ и щракнете върху последния елемент в списъка, „Информация“, ще видите прозорец със строго напомняне относно спазването на авторските права. В допълнение към този текст има не по-малко сериозен код, указващ версията на браузъра. В него с точка са разделени цели четири числа, едно от които вече е надхвърлило четирицифрената граница.

В Google Chrome, в допълнение към също толкова сериозния код на използваната версия (четири числа, разделени с точки), има и индикация за последната налична модификация за инсталиране. За да видите отделен прозорец с цялата тази информация, трябва да отворите менюто, като щракнете върху иконата на гаечен ключ в горния десен ъгъл на прозореца браузъри изберете „Относно Google Chrome“.

В браузъра Apple Safari за всеки случай има два начина да отворите прозорец с информация за версията. Един от тях е подобен на метода на браузъра Chrome - трябва да щракнете върху иконата, разположена на същото място (тук върху нея е нарисувано зъбно колело) и да изберете „За Safari“. Другият е много подобен на Mozilla и IE - трябва да разширите секцията „Помощ“ в менюто и да щракнете върху долния елемент („За Safari“). Apple излезе с най-дългото обозначение на версията: в допълнение към три числа, разделени с точка, има и допълнение от три числа в скоби.