Mengapa dan kapan saya harus membuat kelas 'statis'? Apa tujuan kata kunci 'statis' di kelas?

Kata statickunci pada anggota dalam banyak bahasa berarti Anda tidak boleh membuat turunan dari kelas itu untuk dapat memiliki akses ke anggota itu. Namun, saya tidak melihat adanya pembenaran untuk membuat seluruh kelas static. Mengapa dan kapan saya harus membuat kelas static?

Apa manfaat yang saya dapatkan dari membuat kelas static? Maksud saya, setelah mendeklarasikan kelas statis, kita harus tetap mendeklarasikan semua anggota yang dia ingin akses tanpa instantiasi, sebagai statis juga.

Ini berarti bahwa misalnya, Mathkelas dapat dinyatakan normal (tidak statis), tanpa mempengaruhi cara pengembang kode. Dengan kata lain, membuat kelas statis atau normal agak transparan bagi pengembang.

Itu membuat jelas bagi pengguna bagaimana kelas digunakan. Misalnya, akan menjadi omong kosong untuk menulis kode berikut:

Math m = new Math();

C # tidak harus melarang ini tetapi karena tidak ada gunanya, mungkin juga memberitahu pengguna itu. Orang-orang tertentu (termasuk saya) mematuhi filosofi bahwa bahasa pemrograman (dan API ...) harus seketat mungkin untuk membuat mereka sulit digunakan salah: satu-satunya operasi yang diizinkan adalah mereka yang bermakna dan (mudah-mudahan) benar.

StackOverflow memiliki diskusi hebat tentang topik ini . Untuk memudahkan referensi, saya akan menyalin dan menempelkannya di sini, atas nama penulisnya, Mark S. Rasmussen :

Saya menulis pemikiran saya tentang kelas statis di utas sebelumnya :

Saya dulu suka kelas utilitas diisi dengan metode statis. Mereka melakukan konsolidasi besar metode penolong yang seharusnya bisa menyebabkan redundansi dan pemeliharaan. Mereka sangat mudah digunakan, tidak ada instantiation, tidak ada pembuangan, hanya api 'jangan lupa. Saya kira ini adalah usaha tanpa disadari pertama saya dalam menciptakan arsitektur berorientasi layanan - banyak layanan tanpa kewarganegaraan yang baru saja melakukan pekerjaan mereka dan tidak ada yang lain. Namun ketika sistem tumbuh, naga akan datang.

Polimorfisme

Katakanlah kita memiliki metode UtilityClass.SomeMethod yang dengan senang hati berdengung. Tiba-tiba kita perlu sedikit mengubah fungsionalitas. Sebagian besar fungsinya sama, tetapi kami harus mengubah beberapa bagian. Seandainya itu bukan metode statis, kita bisa membuat kelas turunan dan mengubah konten metode sesuai kebutuhan. Karena ini adalah metode statis, kita tidak bisa. Tentu, jika kita hanya perlu menambahkan fungsionalitas sebelum atau setelah metode yang lama, kita dapat membuat kelas baru dan memanggil yang lama di dalamnya - tetapi itu hanya kotor.

Kesengsaraan antarmuka

Metode statis tidak dapat didefinisikan melalui antarmuka karena alasan logika. Dan karena kita tidak bisa mengesampingkan metode statis, kelas statis tidak berguna ketika kita perlu menyebarkannya melalui antarmuka mereka. Ini membuat kami tidak dapat menggunakan kelas statis sebagai bagian dari pola strategi. Kami mungkin memperbaiki beberapa masalah dengan mengirimkan delegasi alih-alih antarmuka.

Pengujian

Ini pada dasarnya berjalan seiring dengan kesengsaraan antarmuka yang disebutkan di atas. Karena kemampuan kami untuk menukar implementasi sangat terbatas, kami juga akan kesulitan mengganti kode produksi dengan kode uji. Sekali lagi, kita dapat membungkusnya tetapi akan mengharuskan kita untuk mengubah sebagian besar kode kita hanya untuk dapat menerima pembungkus, bukan objek yang sebenarnya.

Menumbuhkan gumpalan

Karena metode statis biasanya digunakan sebagai metode utilitas dan metode utilitas biasanya akan memiliki tujuan yang berbeda, kita akan segera berakhir dengan kelas besar yang diisi dengan fungsionalitas yang tidak koheren - idealnya, setiap kelas harus memiliki tujuan tunggal dalam sistem. Saya lebih suka memiliki lima kali kelas selama tujuan mereka didefinisikan dengan baik.

Parameter creep

Pertama-tama, metode statis kecil yang lucu dan polos itu mungkin mengambil satu parameter. Ketika fungsionalitas tumbuh, beberapa parameter baru ditambahkan. Segera parameter lebih lanjut ditambahkan yang bersifat opsional, jadi kami membuat kelebihan metode (atau hanya menambahkan nilai default, dalam bahasa yang mendukungnya). Tak lama, kami memiliki metode yang mengambil 10 parameter. Hanya tiga yang pertama yang benar-benar diperlukan, parameter 4-7 adalah opsional. Tetapi jika parameter 6 ditentukan, 7-9 harus diisi juga ... Seandainya kita membuat kelas dengan tujuan tunggal melakukan apa yang dilakukan metode statis ini, kita bisa menyelesaikannya dengan mengambil parameter yang diperlukan di konstruktor, dan memungkinkan pengguna untuk menetapkan nilai opsional melalui properti, atau metode untuk mengatur beberapa nilai yang saling tergantung pada saat yang sama. Juga,

Menuntut konsumen untuk membuat instance kelas tanpa alasan

Salah satu argumen yang paling umum adalah, mengapa menuntut agar konsumen kelas kami membuat contoh untuk menggunakan metode tunggal ini, sementara setelah itu tidak menggunakan contoh tersebut? Membuat instance kelas adalah operasi yang sangat sangat murah di sebagian besar bahasa, jadi kecepatan bukanlah masalah. Menambahkan baris kode tambahan ke konsumen adalah biaya rendah untuk meletakkan fondasi solusi yang jauh lebih dapat dipertahankan di masa depan. Dan akhirnya, jika Anda ingin menghindari membuat instance, cukup buat pembungkus tunggal kelas Anda yang memungkinkan untuk digunakan kembali dengan mudah - meskipun ini membuat persyaratan bahwa kelas Anda adalah stateless. Jika tidak stateless, Anda masih bisa membuat metode pembungkus statis yang menangani semuanya, sambil tetap memberi Anda semua manfaat dalam jangka panjang. Akhirnya,

Hanya Sith yang membahas absolut

Tentu saja, ada pengecualian untuk ketidaksukaan saya terhadap metode statis. Kelas utilitas sejati yang tidak menimbulkan risiko kembung adalah kasus yang sangat baik untuk metode statis - System.Convert sebagai contoh. Jika proyek Anda hanya sekali saja tanpa persyaratan untuk pemeliharaan di masa depan, arsitektur keseluruhan benar-benar tidak terlalu penting - statis atau non statis, tidak terlalu penting - kecepatan pengembangan memang demikian.

Standar, standar, standar!

Menggunakan metode instan tidak menghambat Anda untuk juga menggunakan metode statis, dan sebaliknya. Selama ada alasan di balik diferensiasi dan itu standar. Tidak ada yang lebih buruk daripada melihat lapisan bisnis yang luas dengan metode implementasi yang berbeda.

Saya terkejut tidak ada orang lain yang menyebutkan bahwa statickelas mengizinkan metode ekstensi - dengan aman memperluas tipe yang ada (termasuk menambahkan definisi metode ke antarmuka ) yang bukan milik Anda. Misalnya, apa yang ada di Scala

trait MyFoo {
  def foo: Int
  def plusFoo(a: Int) = foo + a
}

dapat dinyatakan dalam C # as

public interface IMyFoo {
  int Foo();
}

public static class MyFooExtensions {
  public static int PlusFoo(this IMyFoo f, int a) {
    return f.Foo() + a;
  }
}

Bagi saya, kelas statis (dalam C #) adalah jenis seperti memanggil suatu fungsi.

Sebagai contoh

public static string DoSomething(string DoSomethingWithThisString){}

Saya melewatkan sebuah string dan mendapatkan kembali string. Semuanya terkandung dalam metode itu. Tidak ada akses ke variabel anggota, dll.

Jujur saja, sebagian besar penggunaannya bagi saya adalah untuk mengurangi baris kode:

Kenapa:

MyClass class = new MyClass();
String s = class.DoSomething("test");

Kapan saya bisa melakukan ini:

String s = MyClass.DoSomething("test");

Jadi, saya akan menggunakan kelas statis dalam kasus-kasus itu, ketika saya ingin melakukan sesuatu tanpa perlu kelas dan berarti lebih sedikit mengetik.

Poin Mark S. valid, tetapi bagi saya jika saya memiliki beberapa metode utilitas lebih mudah untuk berpura-pura saya memanggil fungsi untuk merujuknya sebagai satu baris.

Itu mungkin sederhana, tapi itulah yang saya gunakan static.