Jangan Gunakan "Static" di C #?

Saya mengirimkan aplikasi yang saya tulis ke beberapa arsitek lain untuk tinjauan kode. Salah satu dari mereka segera membalas saya dan berkata "Jangan gunakan" statis ". Anda tidak dapat menulis tes otomatis dengan kelas dan metode statis." Statis "harus dihindari."

Saya memeriksa dan sepenuhnya 1/4 kelas saya ditandai "statis". Saya menggunakan statis ketika saya tidak akan membuat turunan kelas karena kelas tersebut adalah kelas global tunggal yang digunakan di seluruh kode.

Dia kemudian menyebutkan sesuatu yang melibatkan teknik mengejek, IOC / DI yang tidak dapat digunakan dengan kode statis. Dia mengatakan sangat disayangkan ketika perpustakaan pihak ke-3 bersifat statis karena tidak dapat diuji.

Apakah arsitek lain ini benar?

pembaruan: berikut adalah contohnya:

APIManager - kelas ini menyimpan kamus API pihak ke-3 yang saya panggil bersamaan dengan waktu yang diizinkan berikutnya. Ini memberlakukan batas penggunaan API yang dimiliki banyak pihak ke-3 dalam persyaratan layanan mereka. Saya menggunakannya di mana saja saya memanggil layanan pihak ke-3 dengan menelepon Thread.Sleep (APIManager.GetWait ("ProviderXYZ")); sebelum melakukan panggilan. Semua yang ada di sini aman untuk thread dan berfungsi baik dengan TPL di C #.

Itu tergantung pada apakah kelas statis mempertahankan status atau tidak. Secara pribadi, saya tidak punya masalah dengan fungsi stateless yang disatukan dalam kelas statis.

Dia terlalu umum tentang itu. Dia benar, itu menghambat pengujian. Namun, statickelas dan metode memiliki tempat mereka dan itu benar-benar tergantung pada konteksnya. Tanpa contoh kode Anda tidak bisa mengatakannya.

Saya menggunakan statis ketika saya tidak akan membuat turunan kelas karena kelas tersebut adalah kelas global tunggal yang digunakan di seluruh kode.

Ini bisa menjadi bau kode yang parah. Untuk apa Anda menggunakan kelas? Untuk menyimpan data? Untuk mengakses database? Lalu dia benar. Anda harus melihat ke injeksi ketergantungan dalam kasus itu, karena kelas statis seperti itu secara efektif adalah singleton implisit.

Jika Anda menggunakannya untuk metode ekstensi atau bantuan yang tidak mengubah status dan hanya beroperasi pada parameter yang Anda berikan, itu biasanya baik-baik saja.

Saya memeriksa dan sepenuhnya 1/4 kelas saya ditandai "statis". Saya menggunakan statis ketika saya tidak akan membuat turunan kelas karena kelas tersebut adalah kelas global tunggal yang digunakan di seluruh kode.

Hal terbaik untuk dilakukan adalah mencoba dan menguji unit kode Anda. Cobalah merancang tes yang dapat diulang, independen, sederhana, dan uji hanya satu metode pada satu waktu. Coba jalankan tes Anda dalam urutan acak yang berbeda. Bisakah Anda mendapatkan bangunan "hijau" yang stabil?

Jika ya, itu poin yang valid untuk mempertahankan kode Anda. Namun, jika Anda mengalami kesulitan, maka mungkin Anda harus menggunakan metode berbasis contoh.

Jawaban yang sudah diposting mencakup banyak poin yang sangat bagus, tetapi ada satu yang sepertinya tidak ada:

Ladang statis tidak pernah mengumpulkan sampah.

Ini sangat penting jika Anda memiliki aplikasi dengan banyak kendala memori, dan pola ini bisa sangat umum ketika orang mencoba menerapkan cache.

Fungsi statis tidak seburuk itu, tetapi semua orang sudah membahas ini dengan cukup detail.

Salah satu keuntungan yang Anda dapatkan dari IoC / DI adalah bahwa sebagian besar interaksi antar kelas dinegosiasikan antar antarmuka. Ini membuat pengujian unit mudah karena antarmuka dapat diejek secara otomatis atau semi-otomatis, dan karenanya masing-masing bagian dapat diuji untuk input dan output. Selain itu, di luar testabilty, menempatkan antarmuka di antara segalanya memungkinkan Anda untuk memiliki kode yang paling modular - Anda dapat dengan mudah mengganti satu implementasi tanpa begitu banyak khawatir bahwa Anda mengacaukan dependensi.

Karena C # tidak memiliki metaclasses, kelas tidak dapat mengimplementasikan antarmuka menggunakan fitur statis, sehingga fitur statis kelas akhirnya mengacaukan segala upaya untuk menerapkan model objek IoC / DI murni. Artinya, Anda tidak dapat membuat tiruan untuk mengujinya, dan Anda harus membuat dependensi nyata.

Jika perusahaan / proyek Anda banyak berinvestasi dalam melakukan IoC, ini tentu saja merupakan keprihatinan yang masuk akal, dan rasa sakit yang Anda alami adalah untuk keuntungan semua. Dari sudut pandang arsitektur, bagaimanapun, saya pribadi tidak berpikir bahwa model apa pun harus diikuti sampai ke liang kubur. Ada beberapa hal yang masuk akal untuk diimplementasikan menggunakan metode statis - strategi desain tunggal, misalnya. Saya sendiri kurang cenderung ke kelas statis karena saya pikir mereka cenderung mulai kehilangan keunggulan OO, tetapi ada kalanya kelas perpustakaan mungkin ekspresi yang lebih alami dari sesuatu daripada mesin.

Commenter mengingatkan saya pada metode ekstensi, yang tentu saja harus di kelas statis di C #. Itu sah, dan merupakan contoh bagaimana IoC murni tidak bekerja dengan sangat baik di C #, setidaknya jika Anda mencoba memanfaatkan luasnya bahasa.

Kelas statis terkadang disalahgunakan dan harus:

• singleton (di mana kelas non-statis memiliki anggota statis dan variabel Instance statis publik untuk mengambil / membuat hanya satu kali.
• metode di kelas lain (di mana negara penting). Jika Anda memiliki anggota yang tidak menggunakan data dari kelas itu, mungkin itu tidak boleh menjadi bagian dari kelas itu.

Ini juga bisa disebut fungsi 'utilitas', dan bagian dari kelas utilitas. Kelas utilitas adalah kelas yang hanya berisi metode statis dan berfungsi sebagai fungsi pembantu tanpa konteks apa pun.

Metode statis baik untuk digunakan dan memiliki tempat yang tepat dalam pemrograman. Sepertinya arsitek Anda memiliki kerangka pengujian yang tidak sepenuhnya mendukung metode statis. Jika kode Anda adalah bagian dari proyek yang lebih besar, maka penting untuk memenuhi pedoman arsitek. Namun, jangan biarkan proyek ini menghalangi Anda dari menggunakan metode statis ketika tepat untuk melakukannya.

Saya telah menggunakan properti statis untuk hal-hal yang umum untuk semua instance kelas. Dan saya telah menggunakan metode statis untuk mendapatkan kelompok objek kelas. Saya sama sekali tidak ahli tetapi ini telah bekerja untuk saya sejauh ini.

Contoh PHP:

class vendorData {
  private static $data_table = 'vendor_data'; // static property
  private $id; // instance property
  private $name; // instance property

  public function __construct($vendor_id) {
    if(!self::validId($vendor_id) ) { // static method
      return false; // id doesn't exist
    }
    $this->id = $vendor_id; // id has been validated
    $this->getProperties(); // object method
  }

  private static function validId($vendor_id) {
    // send db query to find if the id exists
    // return true/false;
  }

  private function getProperties() { // object method
    $sql = "SELECT * FROM `{self::$data_table}` // using static property
        WHERE `id` = {$this->id}"; // using object instance property
    // get resultset
    foreach($result as $property => $value) {
      $this->$property = $value; // object instance properties all set
    }
  }

  // and here
  public static function getBy($property,$value) { // static method to return object array
    $sql = "SELECT `id` FROM `{self::$data_table}` // using static property
      WHERE `$property` = '$value'";
    // send query, get $ids array
    $obj_array = array();
    foreach($ids as $id) {
      // create array of current class objects using special static keyword
      // meaning of static here is different than in property/method declarations
      $obj_array[$id] = new static($id);
    }
    return $obj_array;
  }
}

Saya akan mengatakan prinsip-prinsip yang mereka miliki baik-baik saja tetapi pernyataan (jangan gunakan statika) mungkin salah. Berapa cakupan kode Anda? jika angkanya tinggi dan Anda merasa nyaman dengan unit testing aplikasi Anda, maka Anda baik-baik saja. Jika tidak, maka saya sarankan meninjau kode. Anda mungkin menemukan kelas statis adalah alasannya atau tidak, itu akan tergantung pada banyak hal.

Kelas dengan metode statis menyalahgunakan prinsip-prinsip OOP. Ini bukan OOP, ini COP - pemrograman berorientasi kelas.

Mereka jarang memiliki "kepribadian" yang jelas (saya menggunakan metafora manusia favorit saya di sini), atau identitas. Jadi mereka tidak tahu siapa mereka. Poin ini saja sudah cukup untuk menyingkirkan konsep ini dalam OOP, tetapi ada lebih banyak dari mereka.

Yang berikutnya adalah konsekuensi dari poin pertama. Karena kelas seperti itu tidak tahu siapa mereka, mereka cenderung dari besar ke besar.

Yang ketiga membuat kode Anda benar-benar tidak dapat dipelihara. Penggunaan metode statis memperkenalkan dependensi tersembunyi . Mereka muncul di semua tempat, dan Anda tidak pernah tahu apa yang terjadi di kelas Anda. Anda tidak bisa memastikan hanya dengan melihat tanda tangan konstruktor.

Perlahan, tetapi tak terhindarkan, kode Anda semakin tidak kohesif, karena dependensi tersembunyi tidak terkontrol dengan baik. Mereka tampak tidak terlihat. Dan sangat mudah untuk menambahkan yang lain! Anda tidak perlu mengubah tanda tangan metode apa pun. Yang harus Anda lakukan adalah memanggil metode statis. Dan apa yang diikuti oleh kode jelek ...

Ok, Anda mungkin sudah menebak. Kopling ketat adalah petugas yang sering kohesi rendah. Jika ada banyak klien menggunakan beberapa kelas, maka kopling semakin ketat. Dan ada godaan besar dalam menggunakan kelas atau metode yang sudah ditulis yang hanya membutuhkan perbaikan kecil. Hanya satu metode flag-parameter.

Apa yang harus digunakan daripada metode statis? Nah, saran saya adalah OOP. Mengapa tidak mencobanya?