Cách triển khai một thuộc tính trên lớp A trong đó đề cập đến một thuộc tính của một đối tượng con của lớp A

Chúng ta có mã này, khi được đơn giản hóa, trông như thế này:

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; }
}

Bây giờ chúng tôi có ba quan điểm.

1) Đây là mã tốt vì thuộc Clienttính phải luôn được đặt (không phải là null) vì vậy Client == nullsẽ không bao giờ xảy ra và giá trị Id 0biểu thị Id sai dù sao (đây là ý kiến ​​của người viết mã ;-))

2) Bạn không thể dựa vào người gọi để biết đó 0là giá trị sai Idvà khi Clienttài sản phải luôn được đặt, bạn nên ném exceptionvào getkhi Clienttài sản xảy ra là null

3) Khi thuộc Clienttính phải luôn được đặt, bạn chỉ cần trả về Client.Idvà để mã ném NullRefngoại lệ khi thuộc Clienttính không có giá trị.

Điều nào là đúng nhất? Hay là có khả năng thứ tư?

Có vẻ như bạn nên giới hạn số lượng trạng thái mà Roomlớp của bạn có thể ở.

Thực tế là bạn đang hỏi về việc phải làm gì khi Clientnull là một gợi ý rằng Roomkhông gian trạng thái quá lớn.

Để đơn giản, tôi sẽ không cho phép Clienttài sản của bất kỳ Roomtrường hợp nào là null. Điều đó có nghĩa là mã bên trong Roomcó thể giả định một cách an toàn Clientlà không bao giờ null.

Nếu vì một lý do nào đó trong tương lai Clienttrở nên nullchống lại sự thôi thúc ủng hộ trạng thái đó. Làm như vậy sẽ tăng sự phức tạp bảo trì của bạn.

Thay vào đó, cho phép mã thất bại và thất bại nhanh chóng. Rốt cuộc, đây không phải là một trạng thái được hỗ trợ. Nếu ứng dụng tự chuyển sang trạng thái này, bạn đã vượt qua một dòng không trả lại. Điều hợp lý duy nhất để làm sau đó là đóng ứng dụng.

Điều này có thể xảy ra (khá tự nhiên) là kết quả của một ngoại lệ tham chiếu null chưa được xử lý.

Chỉ cần một vài cân nhắc:

a) Tại sao lại có một getter dành riêng cho ClientId khi đã có một getter công khai cho chính đối tượng Client? Tôi không thấy lý do tại sao thông tin mà ClientId longphải được khắc trên đá trong chữ ký của Room.

b) Về ý kiến ​​thứ hai, bạn có thể đưa ra một hằng số Invalid_Client_Id.

c) Về ý kiến ​​một và ba (và là điểm chính của tôi): Một phòng phải luôn có khách hàng? Có thể đó chỉ là ngữ nghĩa nhưng điều này không đúng. Có lẽ sẽ phù hợp hơn khi có các lớp hoàn toàn riêng biệt cho Room và Client và một lớp khác gắn kết chúng lại với nhau. Có thể bổ nhiệm, đặt phòng, chiếm dụng? (Điều này phụ thuộc vào những gì bạn thực sự đang làm.) Và trên lớp đó, bạn có thể thực thi các ràng buộc "phải có phòng" và "phải có khách hàng".

Tôi không đồng ý với cả ba ý kiến. Nếu Clientkhông bao giờ có thể null, thì thậm chí đừng biến nó thành có thểnull !

1. Đặt giá trị của Clienttrong hàm tạo
2. Ném một ArgumentNullExceptiontrong các nhà xây dựng.

Vì vậy, mã của bạn sẽ là một cái gì đó như:

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; }
}

Điều này không liên quan đến mã của bạn, nhưng có lẽ bạn nên sử dụng một phiên bản bất biếnRoom bằng cách thực hiện theClient readonly, và sau đó nếu khách hàng thay đổi, tạo một phòng mới. Điều này sẽ cải thiện tính an toàn của chuỗi mã của bạn ngoài sự an toàn vô hiệu của các khía cạnh khác trong câu trả lời của tôi. Xem cuộc thảo luận này về mutable vs bất biến

Các tùy chọn thứ hai và thứ ba nên tránh - getter không nên đánh người gọi bằng một ngoại lệ mà họ không kiểm soát được.

Bạn nên quyết định xem Client có thể là null hay không. Nếu vậy, bạn nên cung cấp một cách để người gọi kiểm tra xem nó có phải là null hay không trước khi truy cập vào nó (ví dụ: thuộc tính bool ClientIsNull).

Nếu bạn quyết định rằng Client không bao giờ có thể là null, thì hãy biến nó thành một tham số bắt buộc cho hàm tạo và ném ngoại lệ vào đó nếu null được truyền vào.

Cuối cùng, tùy chọn đầu tiên cũng chứa mùi mã. Bạn nên để Khách hàng xử lý tài sản ID riêng của mình. Có vẻ như quá mức để mã hóa một getter trong một lớp container mà chỉ đơn giản gọi một getter trên lớp chứa. Chỉ cần hiển thị Khách hàng là tài sản (nếu không, cuối cùng bạn sẽ sao chép mọi thứ mà Khách hàng đã cung cấp ).

long clientId = room.Client.Id;

Nếu Khách hàng có thể là null, thì ít nhất bạn sẽ chịu trách nhiệm cho người gọi:

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

Nếu thuộc tính Client null là trạng thái được hỗ trợ, hãy xem xét sử dụng NullObject .

Nhưng rất có thể đây là một trạng thái đặc biệt, vì vậy bạn nên làm cho nó không thể (hoặc chỉ không thuận tiện lắm) để kết thúc bằng null 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;
}

Tuy nhiên, nếu nó không được hỗ trợ, đừng lãng phí thời gian cho các giải pháp nướng một nửa. Trong trường hợp này:

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

Bạn đã 'giải quyết' NullReferenceException ở đây nhưng với chi phí rất cao! Điều này sẽ buộc tất cả người gọi Room.ClientIdphải kiểm tra 0:

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

Các lỗi lạ có thể xuất hiện với các nhà phát triển khác (hoặc chính bạn!) Quên kiểm tra giá trị trả về "ErrorCode" tại một số thời điểm.
Chơi nó an toàn thất bại nhanh. Cho phép ném NullReferenceException và "duyên dáng" bắt nó ở đâu đó cao hơn ngăn xếp cuộc gọi thay vì cho phép người gọi làm rối tung mọi thứ hơn nữa ...

Ở một lưu ý khác, nếu bạn rất muốn phơi bày Clientvà cũng là ClientIdsuy nghĩ về TellDontAsk . Nếu bạn yêu cầu quá nhiều từ các đối tượng thay vì nói với họ những gì bạn muốn đạt được, bạn có thể kết thúc việc ghép mọi thứ lại với nhau, khiến cho việc thay đổi trở nên khó khăn hơn sau này.

Kể từ c # 6.0, hiện đã được phát hành, bạn chỉ nên làm điều này,

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; }
}

Nâng cao một tài sản của Clientđể Roomlà một sự vi phạm rõ ràng đóng gói và nguyên tắc DRY.

Nếu bạn cần truy cập vào Idmột Clienttrong những điều Roombạn có thể làm,

var clientId = room.Client?.Id;

Lưu ý việc sử dụng Toán tử có điều kiện Null , clientIdsẽ là long?, nếu Clientcó null, clientIdsẽ có null, nếu không clientIdsẽ có giá trị là Client.Id.