Cara mengimplementasikan properti pada kelas A yang mengacu pada properti objek anak kelas A

Kami memiliki kode ini yang, ketika disederhanakan, terlihat seperti ini:

public class Room
{
    public Client Client { get; set; }

    public long ClientId
    {
        get
        {
            return Client == null ? 0 : Client.Id;
        }
    }
}

public class Client 
{
    public long Id { get; set; }
}

Sekarang kami memiliki tiga sudut pandang.

1) Ini adalah kode yang baik karena Clientproperti harus selalu disetel (yaitu bukan nol) sehingga Client == nulltidak akan pernah terjadi dan nilai Id 0menunjukkan ID palsu pula (ini adalah pendapat penulis kode ;-))

2) Anda tidak dapat bergantung pada penelepon untuk mengetahui bahwa itu 0adalah nilai yang salah untuk Iddan ketika Clientproperti harus selalu disetel Anda harus memasukkan exceptionnilai getketika Clientproperti tersebut bernilai nol.

3) Ketika Clientproperti harus selalu disetel, Anda hanya kembali Client.Iddan membiarkan kode tersebut memberikan NullRefpengecualian ketika Clientproperti tersebut bernilai nol.

Manakah dari ini yang paling benar? Atau apakah ada kemungkinan keempat?

Baunya seperti Anda harus membatasi jumlah negara bagian Roomkelas Anda .

Fakta bahwa Anda bertanya tentang apa yang harus dilakukan ketika Clientadalah nol adalah petunjuk bahwa Roomruang keadaan terlalu besar.

Sederhananya, saya tidak akan membiarkan Clientproperti dari Roominstance apa pun menjadi nol. Itu berarti kode di dalamnya Roomdapat dengan aman menganggap Clienttidak pernah nol.

Jika karena alasan tertentu di masa depan Clientmenjadi nullmenahan keinginan untuk mendukung negara itu. Melakukan hal itu akan menambah kompleksitas perawatan Anda.

Sebagai gantinya, biarkan kode gagal dan gagal cepat. Bagaimanapun, ini bukan keadaan yang didukung. Jika aplikasi masuk ke keadaan ini, Anda sudah melewati garis tidak dapat kembali. Satu-satunya hal yang masuk akal untuk dilakukan adalah menutup aplikasi.

Ini mungkin terjadi (secara alami) sebagai hasil dari pengecualian referensi nol yang tidak ditangani.

Hanya beberapa pertimbangan:

a) Mengapa ada pengambil khusus untuk ClientId ketika sudah ada pengambil publik untuk instance Klien itu sendiri? Saya tidak melihat mengapa informasi bahwa ClientId longharus diukir dengan batu di tanda tangan Room.

b) Mengenai pendapat kedua Anda bisa memperkenalkan sebuah konstanta Invalid_Client_Id.

c) Mengenai pendapat satu dan tiga (dan menjadi poin utama saya): Kamar harus selalu memiliki klien? Mungkin hanya semantik tetapi ini kedengarannya tidak benar. Mungkin akan lebih tepat untuk memiliki kelas yang benar-benar terpisah untuk Kamar dan Klien dan kelas lain yang mengikat mereka bersama. Mungkin Pengangkatan, Pemesanan, Hunian? (Ini tergantung pada apa yang sebenarnya Anda lakukan.) Dan pada kelas itu Anda dapat menegakkan batasan "harus memiliki kamar" dan "harus memiliki klien".

Saya tidak setuju dengan ketiga pendapat tersebut. Jika Clienttidak pernah bisa null, maka jangan membuatnya menjadi mungkinnull !

1. Tetapkan nilai Clientdalam konstruktor
2. Lemparkan sebuah ArgumentNullExceptiondi konstruktor.

Jadi kode Anda akan menjadi seperti:

public class Room
{
    private Client theClient;

    public Room(Client client) {
        if(client == null) throw new ArgumentNullException();
        this.theClient = client;
    }

    public Client Client { 
        get { return theClient; }
        set 
        {
            if (value == null) 
                throw new ArgumentNullException();
            theClient = value;
        }
    }

    public long ClientId
    {
        get
        {
            return theClient.Id;
        }
    }
}

public class Client 
{
    public long Id { get; set; }
}

Ini tidak terkait dengan kode Anda, tetapi Anda mungkin akan lebih baik menggunakan versi abadiRoom dengan membuat theClient readonly, dan kemudian jika klien berubah, membuat ruang baru. Ini akan meningkatkan keamanan utas kode Anda selain keamanan nol dari aspek lain dari jawaban saya. Lihat diskusi ini tentang bisa berubah vs tidak berubah

Opsi kedua dan ketiga harus dihindari - rajin dan rajin giat memukul si penelepon dengan pengecualian mereka tidak memiliki kendali atas.

Anda harus memutuskan apakah Klien dapat menjadi nol. Jika demikian, Anda harus menyediakan cara bagi pemanggil untuk memeriksa apakah itu nol sebelum mengaksesnya (misalnya, bool properti ClientIsNull bool).

Jika Anda memutuskan bahwa Klien tidak akan pernah menjadi nol, maka jadikan parameter yang diperlukan untuk konstruktor dan berikan pengecualian di sana jika nol dilewatkan.

Akhirnya, opsi pertama juga berisi kode bau. Anda harus membiarkan Klien berurusan dengan properti ID-nya sendiri. Sepertinya berlebihan untuk membuat kode rajin dan giat dalam kelas wadah yang hanya memanggil rajin dan rajin pada kelas yang ada. Hanya mengekspos Klien sebagai properti (jika tidak, Anda akan akhirnya menduplikasi semua yang sudah ditawarkan oleh Klien ).

long clientId = room.Client.Id;

Jika Klien dapat menjadi nol, maka Anda setidaknya akan memberikan tanggung jawab kepada penelepon:

if (room.Client != null){
    long clientId = room.Client.Id;
    /* other code follows... */
}

Jika properti Klien nol adalah keadaan yang didukung, pertimbangkan untuk menggunakan NullObject .

Tetapi kemungkinan besar ini adalah keadaan yang luar biasa, jadi Anda harus membuatnya tidak mungkin (atau tidak terlalu nyaman) untuk berakhir dengan nol Client:

public Client Client { get; private set; }

public Room(Client client)
{
    Client = client;
}

public void SetClient(Client client)
{
    if (client == null) throw new ArgumentNullException();
    Client = client;
}

Namun jika tidak didukung, jangan buang waktu untuk solusi setengah matang. Pada kasus ini:

return Client == null ? 0 : Client.Id;

Anda telah 'memecahkan' NullReferenceException di sini tetapi dengan biaya yang besar! Ini akan memaksa semua penelepon Room.ClientIduntuk memeriksa 0:

var aRoom = new Room(aClient);
var clientId = aRoom.ClientId;
if (clientId == 0) RestartRoombookingWizard();
else ContinueRoombooking(clientid);

Bug aneh dapat berganti dengan devs lain (atau diri Anda sendiri!) Lupa untuk memeriksa nilai kembali "ErrorCode" di beberapa titik waktu.
Mainkan dengan aman dan gagal dengan cepat. Biarkan NullReferenceException dilempar dan "anggun" tangkap di tempat yang lebih tinggi di tumpukan panggilan alih-alih memungkinkan penelepon mengacaukan segalanya ...

Pada catatan yang berbeda, jika Anda begitu tertarik untuk mengekspos Clientdan juga ClientIdmemikirkan TellDontAsk . Jika Anda bertanya terlalu banyak dari objek alih-alih memberi tahu mereka apa yang ingin Anda capai, Anda dapat mengakhiri menyatukan semuanya, membuat perubahan lebih sulit nantinya.

Pada c # 6.0, yang sekarang dirilis, Anda harus melakukan ini,

public class Room
{
    public Room(Client client)
    {
        this.Client = client;
    }

    public Client Client { get; }
}

public class Client
{
    public Client(long id)
    {
        this.Id = id;
    }

    public long Id { get; }
}

Mengangkat properti Clientke Roommerupakan pelanggaran nyata enkapsulasi dan prinsip KERING.

Jika Anda perlu mengakses Ida Clientdari yang Roomdapat Anda lakukan,

var clientId = room.Client?.Id;

Perhatikan penggunaan Operator Bersyarat Null , clientIdakan menjadi long?, jika Clientada null, clientIdakan null, jika tidak clientIdakan memiliki nilai Client.Id.