Việc sử dụng các thuộc tính được thiết lập của C# có được coi là thực hành tốt không?

Question

câu hỏi của tôi là đơn giản, đang sử dụng các thuộc tính get set của C# được coi là tốt, tốt hơn thậm chí là viết phương thức getter và setter? Khi bạn sử dụng các thuộc tính này, bạn không phải khai báo thành viên dữ liệu lớp của mình là công khai? Tôi hỏi điều này bởi vì giáo sư của tôi nói rằng các thành viên dữ liệu nên không bao giờ được khai báo là công khai, vì nó được coi là thực hành không tốt.

này ....

class GetSetExample 
{ 
    public int someInt { get; set; } 
} 

vs này ...

class NonGetSetExample 
{ 
    private int someInt; 
} 

Edit:

Nhờ tất cả các bạn! Tất cả các câu trả lời của bạn đã giúp tôi và tôi đã bỏ phiếu thích hợp cho câu trả lời của bạn.

Answer 1

này:

class GetSetExample 
{ 
    public int someInt { get; set; } 
} 

là thực sự giống như thế này:

class GetSetExample 
{ 
    private int _someInt; 
    public int someInt { 
     get { return _someInt; } 
     set { _someInt = value; } 
    } 
} 

Cú pháp get; set; chỉ là một cách viết tắt thuận tiện cho việc này mà bạn có thể sử dụng khi phương thức getter và setter không làm bất cứ điều gì đặc biệt.

Vì vậy, bạn không để lộ một thành viên công khai, bạn đang xác định một thành viên riêng và cung cấp các phương thức get/set để truy cập nó.

Answer 2

Trong ví dụ đầu tiên của bạn, C# sẽ tự động tạo các trường sao lưu riêng tư, vì vậy về mặt kỹ thuật, thành viên dữ liệu không được khai báo là chỉ công khai getter/setter.

Answer 3

Khá hợp lý và giáo sư của bạn (không có ngữ cảnh) là sai. Nhưng dù sao, bằng cách sử dụng "tính chất tự động", là tốt, và bạn có thể làm điều đó cho dù họ là công cộng hay tư nhân.

Mặc dù trong kinh nghiệm của tôi, bất cứ khi nào tôi sử dụng, tôi gần như chắc chắn sẽ cần phải viết một số logic trong đó, và do đó không thể sử dụng các đạo cụ tự động.

Answer 4

Có, các thành viên thường không bao giờ được tuyên bố công khai trong thiết kế tốt vì nhiều lý do. Hãy suy nghĩ về OOP, nơi bạn kế thừa lớp sau. Loại khó để ghi đè lên một lĩnh vực. :-) Ngoài ra nó ngăn cản bạn giữ cho nội bộ của bạn không bị truy cập trực tiếp.

Nhận đơn giản; bộ; thiết kế đã được giới thiệu trong C# 2.0. Về cơ bản nó giống như tuyên bố mọi thứ với một thành viên riêng tư ủng hộ nó (dịch ngược nó ra thành công cụ như Reflector và xem).

public int someInt{get;set;} 

bằng trực tiếp đến

private int m_someInt; 
public int someInt{ 
    get { return m_someInt; } 
    set { m_someInt = value; } 
} 

Phần lớn về việc có getter đơn giản/setter là khi bạn muốn điền thông tin vào thực hiện với một chút hơn ruột sau, bạn không phá vỡ Khả năng tương thích ABI.

Đừng lo lắng về getter/setters làm chậm mã của bạn thông qua vô hướng. JIT có một thứ gọi là inlineing làm cho việc sử dụng getter/setter cũng hiệu quả như truy cập trực tiếp.

Answer 5

Trong cách tiếp cận hướng đối tượng "thuần túy", nó không được coi là OK để hiển thị trạng thái của đối tượng của bạn, và điều này áp dụng cho các thuộc tính khi chúng được triển khai trong .NET và get_ set_ properteis của Java/EJB. Ý tưởng là bằng cách phơi bày trạng thái của đối tượng của bạn, bạn đang tạo ra các phụ thuộc bên ngoài để biểu diễn dữ liệu nội bộ của đối tượng của bạn. Một thiết kế đối tượng thuần túy làm giảm tất cả các tương tác với các thông điệp với các tham số.

Trở lại với thế giới thực: nếu bạn cố gắng thực hiện một cách tiếp cận lý thuyết nghiêm ngặt về công việc, bạn sẽ bị cười ra khỏi văn phòng hoặc bị đánh vào bột giấy. Các thuộc tính rất phổ biến bởi vì chúng là một sự thỏa hiệp hợp lý giữa một thiết kế đối tượng thuần túy và dữ liệu riêng được hiển thị đầy đủ.

Answer 6

Có. Thành viên dữ liệu phải là thuộc tính riêng và tự động cho phép nó và cung cấp quyền truy cập công khai đúng cách.

Nhưng bạn nên cẩn thận. Hiểu ngữ cảnh là rất quan trọng. Trong ứng dụng luồng, cập nhật một thuộc tính sau một thuộc tính liên quan khác có thể gây hại cho tính nhất quán. Trong trường hợp đó, một phương thức setter cập nhật hai thành viên dữ liệu riêng theo cách thích hợp sẽ có ý nghĩa hơn.

Answer 7

giáo sư của bạn khá đúng.

Hãy xem xét ví dụ tầm thường này về lý do tại sao "getters" phải tránh: Có thể có 1.000 cuộc gọi đến phương thức getX() trong chương trình của bạn và mọi cuộc gọi đó giả định giá trị trả lại là một loại cụ thể. Giá trị trả lại của getX() có thể được sotred trong một biến địa phương, ví dụ, và kiểu biến phải phù hợp với kiểu trả về. Nếu bạn cần thay đổi cách đối tượng được triển khai theo cách mà loại thay đổi là X, bạn gặp rắc rối nghiêm trọng. Nếu X từng là int, nhưng hiện giờ phải là long, giờ bạn sẽ nhận được 1.000 lỗi biên dịch. Nếu bạn khắc phục sự cố không chính xác bằng cách truyền giá trị trả lại cho int, mã sẽ biên dịch gọn gàng nhưng sẽ không hoạt động. (Giá trị trả lại có thể bị cắt bớt.) Bạn phải sửa đổi mã xung quanh mỗi một trong số 1.000 cuộc gọi đó để bù đắp cho thay đổi. Tôi, ít nhất, không muốn làm nhiều việc đó.

Holub On Patterns

Answer 8

bởi vì với thành viên dữ liệu công cộng, mà thành viên dữ liệu có thể được thay đổi hoặc có thể được đọc ra khỏi lớp và bạn không thể kiểm soát đọc/ghi khả năng tiếp cận hoạt động nhưng với tài sản mà bạn có thể kiểm soát đọc/viết dòng ví dụ xem xét tuyên bố này:

public MyVar{private get; public set;} 

nghĩa giá trị của MyVar có thể thay đổi chỉ bên trong lớp và có thể được đọc ra khỏi lớp (đọc riêng và đọc công khai) và đây không phải là p có thể chỉ với các thành viên dữ liệu công khai