Inisialisasi bidang kelas dalam konstruktor atau deklarasi?

Saya sudah pemrograman di C # dan Java baru-baru ini dan saya ingin tahu di mana tempat terbaik untuk menginisialisasi bidang kelas saya.

Haruskah saya melakukannya di deklarasi ?:

public class Dice
{
    private int topFace = 1;
    private Random myRand = new Random();

    public void Roll()
    {
       // ......
    }
}

atau di konstruktor ?:

public class Dice
{
    private int topFace;
    private Random myRand;

    public Dice()
    {
        topFace = 1;
        myRand = new Random();
    }

    public void Roll()
    {
        // .....
    }
}

Saya benar-benar ingin tahu apa yang menurut sebagian dari Anda veteran adalah praktik terbaik. Saya ingin konsisten dan tetap pada satu pendekatan.

Aturan saya:

1. Jangan menginisialisasi dengan nilai default dalam deklarasi ( null, false, 0, 0.0...).
2. Lebih suka inisialisasi dalam deklarasi jika Anda tidak memiliki parameter konstruktor yang mengubah nilai bidang.
3. Jika nilai bidang berubah karena parameter konstruktor, letakkan inisialisasi pada konstruktor.
4. Konsisten dalam latihan Anda (aturan paling penting).

Dalam C # itu tidak masalah. Dua contoh kode yang Anda berikan benar-benar setara. Dalam contoh pertama kompiler C # (atau itu CLR?) Akan membangun konstruktor kosong dan menginisialisasi variabel seolah-olah mereka berada di konstruktor (ada sedikit nuansa ini yang dijelaskan Jon Skeet dalam komentar di bawah). Jika sudah ada konstruktor maka inisialisasi "di atas" akan dipindahkan ke atasnya.

Dalam hal praktik terbaik, yang pertama lebih sedikit kesalahan daripada yang terakhir karena seseorang dapat dengan mudah menambahkan konstruktor lain dan lupa untuk rantai itu.

Semantik C # sedikit berbeda dari Jawa di sini. Dalam C # penugasan dalam deklarasi dilakukan sebelum memanggil konstruktor superclass. Di Jawa dilakukan segera setelah yang memungkinkan 'ini' untuk digunakan (sangat berguna untuk kelas batin anonim), dan berarti bahwa semantik dari dua bentuk benar-benar cocok.

Jika Anda bisa, buat bidang menjadi final.

Saya pikir ada satu peringatan. Saya pernah melakukan kesalahan seperti itu: Di dalam kelas turunan, saya mencoba untuk "menginisialisasi pada deklarasi" bidang yang diwarisi dari kelas dasar abstrak. Hasilnya adalah bahwa ada dua set bidang, satu adalah "basis" dan yang lain adalah yang baru dinyatakan, dan saya perlu beberapa waktu untuk debug.

Pelajaran: untuk menginisialisasi bidang yang diwariskan , Anda akan melakukannya di dalam konstruktor.

Dengan asumsi jenis dalam contoh Anda, pasti lebih suka menginisialisasi bidang dalam konstruktor. Kasus luar biasa adalah:

• Bidang dalam kelas / metode statis
• Bidang yang diketik sebagai statis / final / et al

Saya selalu memikirkan daftar bidang di bagian atas kelas sebagai daftar isi (apa yang terkandung di sini, bukan bagaimana itu digunakan), dan konstruktor sebagai pengantar. Metode tentu saja adalah bab.

Bagaimana jika saya katakan, itu tergantung?

Secara umum saya menginisialisasi segalanya dan melakukannya dengan cara yang konsisten. Ya itu terlalu eksplisit tetapi juga sedikit lebih mudah untuk dipertahankan.

Jika kita khawatir tentang kinerja, maka saya hanya menginisialisasi apa yang harus dilakukan dan menempatkannya di area yang memberikan hasil terbaik.

Dalam sistem waktu nyata, saya mempertanyakan apakah saya memerlukan variabel atau konstanta sama sekali.

Dan di C ++ saya sering melakukan inisialisasi tanpa di kedua tempat dan memindahkannya ke fungsi Init (). Mengapa? Nah, di C ++ jika Anda menginisialisasi sesuatu yang bisa melempar pengecualian selama konstruksi objek Anda membuka diri untuk kebocoran memori.

Ada banyak dan berbagai situasi.

Saya hanya perlu daftar kosong

Situasinya jelas. Saya hanya perlu menyiapkan daftar saya dan mencegah pengecualian dilemparkan ketika seseorang menambahkan item ke daftar.

public class CsvFile
{
    private List<CsvRow> lines = new List<CsvRow>();

    public CsvFile()
    {
    }
}

Saya tahu nilainya

Saya tahu persis nilai apa yang ingin saya miliki secara default atau saya perlu menggunakan beberapa logika lain.

public class AdminTeam
{
    private List<string> usernames;

    public AdminTeam()
    {
         usernames = new List<string>() {"usernameA", "usernameB"};
    }
}

atau

public class AdminTeam
{
    private List<string> usernames;

    public AdminTeam()
    {
         usernames = GetDefaultUsers(2);
    }
}

Daftar kosong dengan nilai yang mungkin

Terkadang saya mengharapkan daftar kosong secara default dengan kemungkinan menambahkan nilai melalui konstruktor lain.

public class AdminTeam
{
    private List<string> usernames = new List<string>();

    public AdminTeam()
    {
    }

    public AdminTeam(List<string> admins)
    {
         admins.ForEach(x => usernames.Add(x));
    }
}

Di Jawa, penginisialisasi dengan deklarasi berarti bidang selalu diinisialisasi dengan cara yang sama, terlepas dari konstruktor mana yang digunakan (jika Anda memiliki lebih dari satu) atau parameter konstruktor Anda (jika mereka memiliki argumen), meskipun konstruktor mungkin selanjutnya ubah nilainya (jika belum final). Jadi, menggunakan penginisialisasi dengan deklarasi menunjukkan kepada pembaca bahwa nilai yang diinisialisasi adalah nilai yang dimiliki bidang dalam semua kasus , terlepas dari konstruktor mana yang digunakan dan terlepas dari parameter yang diteruskan ke konstruktor mana pun. Oleh karena itu gunakan penginisialisasi dengan deklarasi hanya jika, dan selalu jika, nilai untuk semua objek yang dibangun adalah sama.

Desain C # menyarankan bahwa inisialisasi inline lebih disukai, atau itu tidak akan dalam bahasa. Setiap kali Anda dapat menghindari referensi silang antara berbagai tempat dalam kode, Anda umumnya lebih baik.

Ada juga masalah konsistensi dengan inisialisasi bidang statis, yang harus sesuai untuk kinerja terbaik. Pedoman Kerangka Desain untuk Desain Konstruktor mengatakan ini:

✓ PERTIMBANGKAN inisialisasi bidang statis inline daripada secara eksplisit menggunakan konstruktor statis, karena runtime mampu mengoptimalkan kinerja tipe yang tidak memiliki konstruktor statis yang ditentukan secara eksplisit.

"Pertimbangkan" dalam konteks ini berarti melakukannya kecuali ada alasan kuat untuk tidak melakukannya. Dalam kasus bidang penginisialisasi statis, alasan yang bagus adalah jika inisialisasi terlalu rumit untuk dikodekan secara inline.

Bersikap konsisten itu penting, tetapi ini pertanyaan yang harus Anda tanyakan pada diri sendiri: "Apakah saya memiliki konstruktor untuk hal lain?"

Biasanya, saya membuat model untuk transfer data yang kelas itu sendiri tidak melakukan apa-apa selain berfungsi sebagai perumahan untuk variabel.

Dalam skenario ini, saya biasanya tidak memiliki metode atau konstruktor. Rasanya konyol bagi saya untuk membuat konstruktor untuk tujuan eksklusif menginisialisasi daftar saya, terutama karena saya dapat menginisialisasi mereka sesuai dengan deklarasi.

Jadi seperti yang banyak orang katakan, itu tergantung pada penggunaan Anda. Tetap sederhana, dan jangan membuat tambahan apa pun yang tidak harus Anda lakukan.

Pertimbangkan situasi di mana Anda memiliki lebih dari satu konstruktor. Akankah inisialisasi berbeda untuk konstruktor yang berbeda? Jika mereka akan sama, lalu mengapa mengulangi untuk setiap konstruktor? Ini sesuai dengan pernyataan kokos, tetapi mungkin tidak terkait dengan parameter. Katakanlah, misalnya, Anda ingin menyimpan bendera yang menunjukkan bagaimana objek itu dibuat. Kemudian bendera itu akan diinisialisasi secara berbeda untuk konstruktor yang berbeda terlepas dari parameter konstruktor. Di sisi lain, jika Anda mengulang inisialisasi yang sama untuk setiap konstruktor Anda meninggalkan kemungkinan bahwa Anda (tidak sengaja) mengubah parameter inisialisasi di beberapa konstruktor tetapi tidak pada yang lain. Jadi, konsep dasar di sini adalah bahwa kode umum harus memiliki lokasi yang sama dan tidak berpotensi diulang di lokasi yang berbeda.

Ada sedikit manfaat kinerja untuk menetapkan nilai dalam deklarasi. Jika Anda mengaturnya di konstruktor itu sebenarnya sedang diatur dua kali (pertama ke nilai default, kemudian reset di ctor).

Saya biasanya mencoba konstruktor untuk melakukan apa-apa selain mendapatkan dependensi dan menginisialisasi anggota contoh terkait dengan mereka. Ini akan membuat hidup Anda lebih mudah jika Anda ingin menguji kelas Anda.

Jika nilai yang akan Anda tetapkan ke variabel instan tidak terpengaruh oleh parameter apa pun yang akan Anda berikan kepada Anda konstruktor, maka tetapkan pada waktu deklarasi.

Bukan jawaban langsung untuk pertanyaan Anda tentang praktik terbaik tetapi poin penyegaran penting dan terkait adalah bahwa dalam kasus definisi kelas generik, biarkan di kompiler untuk menginisialisasi dengan nilai default atau kita harus menggunakan metode khusus untuk menginisialisasi bidang ke nilai default mereka (jika itu mutlak diperlukan untuk pembacaan kode).

class MyGeneric<T>
{
    T data;
    //T data = ""; // <-- ERROR
    //T data = 0; // <-- ERROR
    //T data = null; // <-- ERROR        

    public MyGeneric()
    {
        // All of the above errors would be errors here in constructor as well
    }
}

Dan metode khusus untuk menginisialisasi bidang generik ke nilai default adalah sebagai berikut:

class MyGeneric<T>
{
    T data = default(T);

    public MyGeneric()
    {           
        // The same method can be used here in constructor
    }
}

Saat Anda tidak memerlukan penanganan logika atau kesalahan:

• Inisialisasi bidang kelas pada deklarasi

Saat Anda membutuhkan penanganan logika atau kesalahan:

• Inisialisasi bidang kelas dalam konstruktor

Ini bekerja dengan baik ketika nilai inisialisasi tersedia dan inisialisasi dapat diletakkan pada satu baris. Namun, bentuk inisialisasi ini memiliki keterbatasan karena kesederhanaannya. Jika inisialisasi memerlukan beberapa logika (misalnya, penanganan kesalahan atau loop untuk mengisi array yang kompleks), tugas sederhana tidak memadai. Variabel instan dapat diinisialisasi dalam konstruktor, di mana penanganan kesalahan atau logika lainnya dapat digunakan.

Dari https://docs.oracle.com/javase/tutorial/java/javaOO/initial.html .