"Eksternal" dalam konteks ini berarti "dapat diamati oleh pengguna". Pengguna mungkin manusia dalam hal aplikasi, atau program lain dalam kasus API publik.
Jadi, jika Anda memindahkan metode M dari kelas A ke kelas B, dan kedua kelas tersebut berada jauh di dalam suatu aplikasi, dan tidak ada pengguna yang dapat mengamati perubahan perilaku aplikasi karena perubahan tersebut, maka Anda dapat dengan tepat menyebutnya refactoring.
Jika, OTOH, beberapa subsistem / komponen tingkat tinggi lainnya mengubah perilakunya atau rusak karena perubahan, yang memang (biasanya) dapat diamati oleh pengguna (atau setidaknya sysadmin memeriksa log). Atau jika kelas Anda adalah bagian dari API publik, mungkin ada kode pihak ke-3 di luar sana yang bergantung pada M sebagai bagian dari kelas A, bukan B. Jadi, tidak satu pun dari kasus ini yang refactoring dalam arti yang ketat.
ada kecenderungan untuk menyebut kode ulang sebagai refactoring yang, saya kira, salah.
Memang, itu adalah konsekuensi yang menyedihkan tetapi diharapkan dari refactoring menjadi modis. Pengembang telah melakukan pengerjaan ulang kode secara ad hoc selama bertahun-tahun, dan tentu saja lebih mudah untuk mempelajari kata kunci baru daripada menganalisis dan mengubah kebiasaan yang sudah tertanam.
Jadi apa kata yang tepat untuk pengerjaan ulang yang mengubah perilaku eksternal?
Saya akan menyebutnya desain ulang .
Memperbarui
Banyak jawaban menarik tentang antarmuka, tetapi tidakkah memindahkan metode refactoring mengubah antarmuka?
Dari apa? Kelas spesifik, ya. Tetapi apakah kelas-kelas ini langsung terlihat oleh dunia luar? Jika tidak - karena mereka ada di dalam program Anda, dan bukan bagian dari antarmuka eksternal (API / GUI) dari program - tidak ada perubahan yang dibuat yang dapat diamati oleh pihak eksternal (kecuali perubahan itu menghancurkan sesuatu, tentu saja).
Saya merasa bahwa ada pertanyaan yang lebih dalam di luar ini: apakah kelas tertentu ada sebagai entitas independen dengan sendirinya? Dalam kebanyakan kasus, jawabannya adalah tidak : kelas hanya ada sebagai bagian dari komponen yang lebih besar, ekosistem kelas dan objek, tanpanya kelas tidak dapat dipakai dan / atau tidak dapat digunakan. Ekosistem ini tidak hanya mencakup dependensi (langsung / tidak langsung), tetapi juga kelas / objek lain yang bergantung padanya. Ini karena tanpa kelas tingkat yang lebih tinggi ini, tanggung jawab yang terkait dengan kelas kami mungkin tidak ada artinya / tidak berguna bagi pengguna sistem.
Misalnya dalam proyek kami yang berkaitan dengan penyewaan mobil, ada a Chargekelas. Kelas ini tidak digunakan oleh pengguna sistem itu sendiri, karena agen dan pelanggan stasiun penyewaan tidak dapat berbuat banyak dengan biaya individu: mereka berurusan dengan kontrak perjanjian sewa secara keseluruhan (yang mencakup banyak jenis biaya yang berbeda) . Para pengguna sebagian besar tertarik pada jumlah total biaya ini, bahwa mereka harus membayar pada akhirnya; agen tertarik pada opsi kontrak yang berbeda, panjang sewa, grup kendaraan, paket asuransi, item tambahan dll. dipilih, yang (melalui aturan bisnis canggih) mengatur biaya apa yang ada dan bagaimana pembayaran akhir dihitung dari ini. Dan perwakilan negara / analis bisnis peduli dengan aturan bisnis tertentu, sinergi dan efeknya (terhadap pendapatan perusahaan, dll.).
Baru-baru ini saya refactored kelas ini, mengganti nama sebagian besar bidang dan metode (untuk mengikuti konvensi penamaan Java standar, yang benar-benar diabaikan oleh para pendahulu kami). Saya juga merencanakan refactoring lebih lanjut untuk mengganti Stringdan charbidang dengan jenis enumdan yang lebih tepat boolean. Semua ini tentu saja akan mengubah antarmuka kelas, tetapi (jika saya melakukan pekerjaan saya dengan benar) tidak ada yang akan terlihat oleh pengguna aplikasi kami. Tak satu pun dari mereka yang peduli tentang bagaimana biaya individu yang diwakili, meskipun mereka pasti tahu konsep biaya. Saya bisa saja memilih sebagai contoh seratus kelas lain yang tidak mewakili konsep domain apa pun, jadi bahkan secara konsep tidak terlihat oleh pengguna akhir, tetapi saya pikir lebih menarik untuk mengambil contoh di mana setidaknya ada beberapa visibilitas pada tingkat konsep. Ini menunjukkan dengan baik bahwa antarmuka kelas hanya merupakan representasi dari konsep domain (paling-paling), bukan yang asli *. Representasi dapat diubah tanpa mempengaruhi konsep. Dan pengguna hanya memiliki dan memahami konsep; itu adalah tugas kita untuk melakukan pemetaan antara konsep dan representasi.
* Dan kita dapat dengan mudah menambahkan bahwa model domain, yang diwakili oleh kelas kita, itu sendiri hanyalah representasi perkiraan dari beberapa "hal nyata" ...