"Зовнішній" у цьому контексті означає "спостережливий для користувачів". Користувачі можуть бути людьми у випадку програми або інших програм у разі публічного API.
Отже, якщо ви пересунете метод M з класу A до класу B, і обидва класи знаходяться всередині програми, і жоден користувач не може спостерігати будь-які зміни в поведінці програми через зміну, то ви можете правильно називати його рефакторинг.
Якщо, OTOH, якась інша підсистема / компонент вищого рівня змінює свою поведінку або розривається через зміну, що дійсно (як правило) спостерігається для користувачів (або принаймні для системних адміністраторів, що перевіряють журнали). Або якщо ваші класи були частиною загальнодоступного API, там може бути код сторонніх сторін, який залежить від того, що M є частиною класу A, а не B. Отже, жоден з цих випадків не є рефакторингом у строгому сенсі.
є тенденція називати будь-який код переробки як рефакторинг, який, я думаю, неправильний.
Дійсно, це сумний, але очікуваний наслідок того, що рефакторинг стане модним. Розробники займаються переробкою коду спеціально протягом віків, і, безумовно, легше вивчити нову модну слово, ніж аналізувати та змінювати вроджені звички.
Отже, яке правильне слово для змін, які змінюють зовнішню поведінку?
Я б назвав це переробкою .
Оновлення
Дуже багато цікавих відповідей про інтерфейс, але чи не зрушив би метод рефакторингу змінити інтерфейс?
Якого? Конкретні класи, так. Але чи видимі ці класи безпосередньо зовнішнім світом? Якщо ні - тому, що вони знаходяться всередині вашої програми, а не є частиною зовнішнього інтерфейсу (API / GUI) програми - жодні зміни, внесені там, не спостерігаються зовнішніми сторонами (якщо, звичайно, зміна щось не порушує).
Я відчуваю, що поза цим існує глибше питання: чи існує конкретний клас як самостійний суб'єкт сам по собі? У більшості випадків відповідь " ні" : клас існує лише як частина більшого компонента, екосистеми класів та об'єктів, без якого він не може бути інстанційним та / або непридатним. Ця екосистема включає не лише її (прямі / непрямі) залежності, але й інші класи / об'єкти, які залежать від неї. Це тому, що без цих класів вищого рівня відповідальність, пов’язана з нашим класом, може бути безглуздою / марною для користувачів системи.
Наприклад, у нашому проекті, який стосується прокату автомобілів, є Chargeклас. Цей клас не користується користувачами системи сам по собі, оскільки агенти прокату та клієнти не можуть багато зробити з індивідуальною платою: вони мають справу з договорами оренди в цілому (які включають купу різного роду платежів) . Користувачів найбільше цікавить сума цих зборів, яку вони повинні сплатити в підсумку; агент цікавиться різними варіантами договору, тривалістю оренди, групою транспортних засобів, страховим пакетом, додатковими предметами тощо тощо. Вибрано, що (за допомогою складних правил бізнесу) регулює, які тарифи є і як розраховується остаточний платіж поза цим. А представники країни / бізнес-аналітики дбають про конкретні правила бізнесу, їх синергію та вплив (на доходи компанії тощо).
Нещодавно я відновив цей клас, перейменувавши більшість його полів та методів (дотримуючись стандартної конвенції про іменування Java, якою наші попередники повністю знехтували). Я також планую подальші реконструкції для заміни Stringта charполів на більш відповідні enumта booleanтипи. Все це, безумовно, змінить інтерфейс класу, але (якщо я правильно виконую свою роботу) жоден з них не стане видимим для користувачів нашого додатку. Жоден з них не переймається тим, як представлені індивідуальні збори, хоча вони, безумовно, знають поняття заряду. Я міг би вибрати для прикладу сотню інших класів, що не представляють жодної концепції домену, тому будучи навіть концептуально непомітним для кінцевих користувачів, але я вважав, що цікавіше вибрати приклад, коли на рівні концепції є хоч якась видимість. Це добре показує, що інтерфейси класів - це лише представлення доменних понять (у кращому випадку), а не реальна річ *. Представлення можна змінити, не впливаючи на концепцію. А користувачі лише і розуміють концепцію; наше завдання - зробити відображення між концепцією та представленням.
* І можна легко додати, що модель домену, яку представляє наш клас, сама по собі є лише приблизним поданням якоїсь "реальної речі" ...