sử dụng đúng của C thuộc tính #

Question

private List<Date> _dates; 

public List<Date> Dates 
{ 
    get { return _dates; } 
    set { _dates = value; } 
} 

HOẶC

public List<Date> Dates 
{ 
    get;   
    set;  
} 

Tôi đã luôn được sử dụng trước đây, là thực hành sai hay xấu? Nó không bao giờ xảy ra với tôi rằng tôi chỉ có thể sử dụng tùy chọn thứ hai. Tôi thích có các biến đóng gói của tôi để bắt đầu với dấu gạch dưới để tôi có thể phân biệt chúng với các tham số phương thức. Và tôi đã luôn luôn làm theo cách đó.

Có thể sử dụng tùy chọn đầu tiên sẽ dẫn đến một đối tượng thêm List<Date> được khởi tạo và sau đó toàn bộ _dates được thay thế bằng value hoặc thông minh hơn?

Ngoài ra, điều nổi bật nhất trong ngành hoặc là hoàn toàn chủ quan?

Answer 1

Chúng tương đương với biểu mẫu được biên dịch bên trong, ngoại trừ việc bạn không thể truy cập biến riêng được tạo trong trình biên dịch ở dạng thứ hai.

Từ quan điểm mã hiệu quả, chúng tương đương nhau, trình biên dịch trong thời gian thường trực tiếp truy cập biến riêng tư mà không cần gọi hàm truy cập (sau khi môi trường thời gian chạy đã kiểm tra khả năng truy cập v.v.).

Từ góc độ mã hóa, tôi thích phiên bản thứ hai gọn hơn (ít viết hơn, ít đọc hơn).

Cú pháp thứ hai được giới thiệu trong C# 3.0. Vì vậy, biến thể đầu tiên sẽ tương thích hơn với các trình biên dịch cũ.

Answer 2

Cả hai đều cơ bản giống nhau vì cách .NET biên dịch các thuộc tính tự động. Các thuộc tính tự động đã có sẵn với .NET 3.5.

Answer 3

Sử dụng tên cũ nếu bạn cần thêm một số loại logic vào bộ thu thập/giải quyết của bạn.

Sử dụng cách khác. Nó làm cho mọi thứ sạch hơn nhiều. Bạn cũng có thể đạt được chỉ đọc thuộc tính sử dụng các thuộc tính tự động:

public List<Date> Dates { get; private set; } 

Hoặc, nếu bạn không muốn mọi người thêm bất kỳ mặt hàng vào danh sách thông qua sở hữu, bạn có thể dùng đến cú pháp cũ:

private List<Date> _dates = new List<Date>(); 
private ReadOnlyCollection<Date> _readOnlyDates = 
    new ReadOnlyCollection<Date>(_dates); 

public ReadOnlyCollection<Date> Dates 
{ 
    get { return _readOnlyDates; } 
} 

Answer 4

Nó không quan trọng. Thứ hai chỉ là đường. Tôi luôn luôn sử dụng thứ hai bởi vì nó sạch hơn, nhưng mỗi một lần trong một thời gian tôi cần truy cập vào giá trị ủng hộ.

Answer 5

Miễn là bạn không phải đảm bảo rằng List<Date> được khởi tạo trong trình khởi động, bạn có thể sử dụng cả hai phiên bản. Tôi chỉ gợi ý rằng bạn đang sử dụng một phiên bản và bạn không pha trộn nó trong mã của bạn ...

Nếu bạn cần khởi tạo bạn phải đi cho phiên bản đầu tiên ...

private List<Date> _dates; 

public List<Date> Dates 
{ 
    get { if (_dates == null) _dates = new List<Date>(); return _dates; } 
    set { _dates = value; } 
} 

Answer 6

tôi tin rằng họ biên dịch thành cùng một mã. Sau này chỉ là cú pháp để đại diện cho cái cũ. Tôi có xu hướng nghĩ về sau này như một trình giữ chỗ cho logic trong tương lai mà có thể cần phải được đặt trong các thuộc tính, tại thời điểm đó tôi muốn chuyển đổi các thuộc tính bị ảnh hưởng cho trước đó.

Answer 7

Hai số này được biên dịch gần như giống nhau (Tôi không biết rằng tên của trường sao lưu sẽ giống nhau, nhưng chúng sẽ có chức năng tương đương).

IIRC, khả năng thực hiện Thuộc tính tự động (public List<Date> Dates {get; set;}) đã được thêm vào trong .NET 3.0 hoặc 3.5.

Answer 8

Tôi có xu hướng sử dụng thuộc tính tự động hơn vì thuộc tính là cách hay để thể hiện ý định về những gì đối tượng của bạn đang làm, nhưng vẫn có một số bảo vệ.

Hầu như tất cả các tờ khai tài sản của tôi trông giống như:

public bool IsBlah { get; private set; } 

này làm cho nó một getter đẹp, dễ đọc, và được bảo vệ.

Nhưng có những lúc bạn muốn có một lĩnh vực ủng hộ rõ ràng:

private bool? _isBlah; 
public bool IsBlah 
{ 
    get 
    { 
     if (_isBlah == null) 
     { 
      // Do something expensive here and set _isBlah 
      _isBlah = true; 
     } 
     return _isBlah; 
    } 
} 

Answer 9

Điều thứ nhất là cách tiếp cận ban đầu, sau này là một ví dụ về các thiết bị mới hơn 'thuộc tính tự động' theo đó trình biên dịch sẽ tạo ra một lĩnh vực sao lưu cho bạn tự động.

Một số người (trong đó có tôi) né tránh các thuộc tính tự động vì cú pháp là dễ nhầm lẫn đối với tài sản trừu tượng, không có cơ sở cho 'readonly' tài sản và cú pháp cho các thuộc tính tự động với setters tin là vụng về:

public List Dates 
{ 
    get; 
    private set; 
}

Tôi cũng cảm thấy không thoải mái khi có các trường truy cập triển khai nội bộ của lớp học thông qua API lớp học.

Answer 10

Biến thể thứ hai được biết là auto-implemented properties và được giới thiệu trong C# 3.0 (do đó tại sao bạn có thể chưa gặp phải trước đó).

Nên sử dụng định dạng này nếu bạn muốn tạo thuộc tính đơn giản với trường sao lưu và không cần thực hiện bất kỳ logic nào trong 'getter' và 'setter'. Nó không chỉ ngắn gọn hơn, mà nó còn buộc bạn truy cập trực tiếp vào tài sản, thay vì trải qua lĩnh vực sao lưu, đó là cách thực hành tốt nhất.

Lưu ý rằng bạn vẫn có thể khởi tạo thuộc tính, bạn chỉ cần thực hiện thông qua hàm tạo.

public class MyClass 
{ 

    public List<Date> Dates 
    { 
     get;   
     set;  
    } 

    public MyClass() 
    { 
     Dates = new List<Date>(); 
    } 

} 

Answer 11

Theo như tôi có thể nhớ, tôi luôn quản lý các thuộc tính danh sách của mình từ bên trong đối tượng, làm cho chúng chỉ đọc.

private IList<DateTime> _dates; 

public MyClass() { 
    _dates = new List<DateTime>(); 
} 

public IList<DateTime> Dates { 
    get { 
     return _dates; 
    } 
} 

Bằng cách đó, tôi đảm bảo rằng danh sách của tôi là không bao giờ null khi tôi truy cập vào nó, kể từ khi khách hàng không thể gán nó.

Tuy nhiên, ví dụ của bạn, bạn chỉ cần sử dụng phương pháp tiếp cận cũ nếu bạn cần một số loại logic khi nhận hoặc đặt thuộc tính. Nếu không, các thuộc tính tự động thực hiện chính xác như bạn muốn, chỉ nhận và thiết lập một giá trị cho một trường riêng. Hơn nữa, các { get; set; } cải thiện khả năng đọc và giúp các lập trình viên khác hiểu ý định của bạn, theo quan điểm khiêm nhường của tôi.

Ví dụ:

public class MyClass { 
    private IList<DateTime> _dates; 

    public IList<DateTime> Dates { 
     get { 
      return _dates; 
     } set { 
      _dates = value; 
     } 
    } 
} 

so

public class MyClasse { 
    public IList<DateTime> Dates { get; set; } 
} 

Cách thứ hai làm cho nó gọn gàng hơn và mau lẹ hơn, ít nhất là với tôi, những gì mục đích là. Và nó trở nên nhanh hơn để mã hóa một lớp, khi không có logic bên trong getter và setter là cần thiết.

Nếu không, cái này không tốt hơn cái kia và hoàn toàn giống nhau, nói về việc nhận và đặt đơn giản giá trị của tài sản mà không có logic.

Quan trọng nhất, bạn cần phải thoải mái với mã của mình. Nếu nó kết thúc cho bạn không nhận được bất kỳ cải tiến, và bạn thích những gì bạn đang làm, hơn là chỉ làm điều đó. =)

Answer 12

Cá nhân tôi thích phương pháp đầu tiên vì nó cho phép bạn thực hiện một vài thao tác trước khi trả lại.

E.G. (Một ví dụ thực sự nghèo)

private int _limit; 
    private int _onHand; 
    private bool returnToVendor; 

    public Item(int limit, int onHand) 
    { 
     _limit = limit; 
     _onHand = onHand; 
    } 

    public int ReturnStock 
    { 
     get 
     { 
     if(_onHand > _limit) 
     { 
      returnToVendor = true; 
      return _onHand; 
     } 
     } 

     set 
     { 
      _onHand = value; 

      if(_onHand < _limit) 
      { 
       returnToVendor = false; 
      } 
     } 
    }