Saya baru-baru ini meninjau beberapa kelas statis "utilitas tas" Helper mengambang di sekitar beberapa kode C # besar yang saya kerjakan, hal-hal yang pada dasarnya seperti cuplikan yang sangat ringkas:
// Helpers.cs
public static class Helpers
{
public static void DoSomething() {}
public static void DoSomethingElse() {}
}Metode spesifik yang saya ulas adalah
- sebagian besar tidak terkait satu sama lain,
- tanpa negara eksplisit bertahan di doa,
- kecil, dan
- masing-masing dikonsumsi oleh berbagai jenis yang tidak terkait.
Sunting: Di atas tidak dimaksudkan untuk menjadi daftar masalah yang diduga. Ini adalah daftar karakteristik umum dari metode spesifik yang saya ulas. Konteksnya untuk membantu jawaban memberikan solusi yang lebih relevan.
Hanya untuk pertanyaan ini, saya akan merujuk pada metode semacam ini sebagai GLUM (metode utilitas umum ringan). Konotasi negatif "murung" sebagian dimaksudkan. Saya minta maaf jika ini dianggap sebagai permainan kata bodoh.
Bahkan mengesampingkan skeptisisme default saya sendiri tentang GLUM, saya tidak suka hal-hal berikut tentang ini:
- Kelas statis digunakan hanya sebagai namespace.
- Identifier kelas statis pada dasarnya tidak ada artinya.
- Ketika GLUM baru ditambahkan, baik (a) kelas "tas" ini disentuh tanpa alasan yang baik atau (b) kelas "tas" baru dibuat (yang dengan sendirinya biasanya tidak menjadi masalah; yang buruk adalah bahwa baru kelas statis sering hanya mengulangi masalah yang tidak terkait, tetapi dengan metode yang lebih sedikit).
- Meta-penamaan adalah tak terelakkan mengerikan, non-standar, dan biasanya secara internal tidak konsisten, apakah itu
Helpers,Utilities, atau apa pun.
Apa pola yang cukup bagus & sederhana untuk refactoring ini, sebaiknya mengatasi masalah di atas, dan lebih disukai dengan sentuhan seringan mungkin?
Saya mungkin harus menekankan: Semua metode yang saya hadapi tidak berpasangan satu sama lain. Tampaknya tidak ada cara yang masuk akal untuk memecahnya menjadi tas metode kelas statis yang lebih halus namun tetap multi-anggota.
