Làm thế nào để bạn thường bố trí các khu vực của một lớp?

Tôi đã tự hỏi nếu có một tiêu chuẩn để đặt ra các khu vực của một lớp học.

Tôi hiện đang sử dụng

Fields
Constructor
Properties
Public Methods
Private Methods

Fieldslà tài sản riêng tư và Propertieslà tài sản công cộng. Thông thường tôi sẽ sử dụng các tiểu vùng trong đó nếu cần hoặc đôi khi sẽ thêm các khu vực khác bên dưới (chẳng hạn như các thành viên cơ sở hoặc giao diện).

Enums liên quan đến lớp hoặc đôi khi cấu trúc / lớp dữ liệu thuần túy (trên định nghĩa lớp thực tế)

--- Định nghĩa lớp ---

Thành viên tư nhân

CTOR / DTOR nếu ngôn ngữ có DTOR

Tài sản công cộng

Các phương thức tiện ích (phương thức riêng tư hoặc được bảo vệ với phạm vi nhỏ)

Chức năng của lớp (Có thể được chia thành nhiều vùng tùy theo phạm vi của lớp).

Tiểu vùng? Lớp học của bạn có một trách nhiệm duy nhất ? .

Tôi chỉ muốn xác nhận rằng bạn có nghĩa là "#regions" chứ không phải bố cục lớp nói chung.

Tôi ngạc nhiên không ai đề cập đến để tránh sử dụng các khu vực. Tôi hiểu rằng OP muốn thực hiện một cuộc thăm dò ý kiến ​​về việc đặt ra các khu vực, nhưng tôi muốn đưa ra một quan điểm khác.

Tôi tránh các khu vực. Tôi muốn xem mã tôi đang làm việc với. Nếu bạn cảm thấy khó khăn để tìm thấy những gì bạn đang tìm kiếm thì hãy sử dụng mã gấp và nhóm các cấu trúc lớp tương tự lại với nhau.

Tại sao tôi ghét các khu vực? CTRL+M,Lvà CTRL+M,Osẽ chuyển mã gấp. Tuy nhiên, khi sụp đổ nó che giấu toàn bộ khu vực. Tôi chỉ cần thu gọn các phương thức / thuộc tính / bình luận.

Nếu có quá nhiều vùng, có thể đó là mùi mã và lớp của bạn đang làm quá nhiều việc. Jeff Atwood cung cấp một bài viết tốt về các khu vực đáng đọc.

Trích dẫn yêu thích của tôi trên #regions:

Không, tôi sẽ không sử dụng #regions. Và không, tôi KHÔNG NEGOTIATE VỚI TERRORIST. Câm miệng.

- Jeff Atwood

Điều đó đang được nói, tôi biết nhiều lập trình viên khăng khăng sử dụng chúng. Câu hỏi này là một chủ quan. Tôi chỉ nghĩ rằng tôi sẽ cung cấp một sự thay thế.

Nó thay đổi từ ngôn ngữ để ngôn ngữ. Vì tôi là một lập trình viên Delphi, tôi có xu hướng tuân theo quy ước chuẩn Delphi, trông giống như sau:

type
  TMyClass = class(TBaseClass)
  private
    private fields
    private methods
  protected
    protected fields
    protected methods
    protected properties
  public
    constructor(s)
    destructor
    public methods
    public properties
  end;

Tôi thấy đó là một cách tốt để tổ chức thông tin dễ đọc và dễ hiểu.

Tôi có xu hướng đặt chúng ra theo cách sau:

Public fields (usually static constants)
Constructors
Public methods
Private methods
Private fields

Không sử dụng một ngôn ngữ sử dụng Propertiesvì vậy đó là lý do tại sao những ngôn ngữ đó không được đặt ra. Tôi đặt các phương thức và trường riêng ở dưới cùng vì nếu có ai đó đang sử dụng tệp này trong mã của họ, họ chỉ cần quan tâm đến API, đó là công cụ công khai. Và tất cả các trình soạn thảo văn bản mà tôi biết và thậm chí cả IDE đều đặt con trỏ ở trên cùng khi mở tệp.

Đó là một cuộc gọi phán xét cho tôi. Tôi sử dụng các vùng khi chúng cần thiết cho khả năng đọc.

Tôi cũng sử dụng một màu khác trong bảng màu Visual Studio của mình (hiện tại là màu đỏ sẫm) để làm cho chúng nổi bật so với phần còn lại của mã.

Một ví dụ về nơi tôi có thể sử dụng #region: Nếu tôi viết phương thức thử nghiệm cho một thử nghiệm đơn vị yêu cầu một đoạn mã XML nhiều dòng, chuỗi XML sẽ phá vỡ vết lõm thông thường (vì nó bắt đầu dọc theo lề trái của cửa sổ mã. Để che giấu sự xấu xí, tôi sẽ bọc nó trong một #region, để tôi có thể thu gọn nó.

Cuốn sách Clean Code của Bob Martin dành toàn bộ chương thứ 5 để định dạng. Có một vài điểm chính mà tôi cảm thấy tóm tắt nó một cách độc đáo.

• Hầu hết các nỗ lực để nhóm các biến và phương thức theo mức độ hiển thị và độ sạch Không có nhiều ý nghĩa và khiến bạn phải điều hướng xung quanh mã rất nhiều.
• Giữ các phương thức gọi nhau theo chiều dọc sẽ giảm lượng điều hướng bạn cần thực hiện và giúp tìm đồ dễ dàng hơn.
• Chuyến tàu tư tưởng của bạn sẽ không bị phá vỡ nếu bạn phải dừng lại và nghĩ rằng "đoạn mã này thuộc về vùng nào?" cứ sau vài phút
• Các biến sơ thẩm thường nên có ít và có khả năng được sử dụng ở mọi nơi, do đó chúng thuộc về đầu của lớp nơi chúng sẽ dễ dàng xác định vị trí nhất. Các biến và khai báo sẽ chỉ được sử dụng bởi một phương thức cần tồn tại bên trong phương thức đó. Nếu chỉ được sử dụng bởi một vài phương thức, thì chúng nên được đóng theo chiều dọc nhưng trên một vài phương thức đang sử dụng chúng.

Giữ mã của bạn được sắp xếp với các yếu tố thường tương tác theo chiều dọc gần nhau sẽ loại bỏ hiệu quả mọi nhu cầu tạo các vùng cụ thể. Nếu mã của bạn quá dài đến nỗi nó yêu cầu các vùng ẩn rất nhiều mã, thì có lẽ đó là mùi mã cho biết rằng lớp đang cố gắng làm quá nhiều. Có lẽ một số chức năng có thể được chuyển ra một lớp tiện ích hoặc được đẩy lên tổ tiên.

Nếu bạn cần "ẩn" mã bởi vì nó quá dài hoặc quá "xấu xí", thì có lẽ bạn đã gặp phải vấn đề lớn hơn là lo lắng về việc có nên sử dụng các vùng hay không. Cá nhân tôi không bao giờ cần sử dụng chúng, và khi làm việc với mã của người khác, tôi thấy tôi luôn cần phải mở tất cả chúng ra, vậy tại sao phải bận tâm?

Tôi hiện đang bố trí các lớp như thế này:

class types
constructors
destructor
accessors
methods
properties (where properties are present in the language)
member variables

và sau đó tiền tố mức truy cập cho mỗi khai báo (sắp xếp, đôi khi nhóm theo quyền truy cập). Tôi đã từng thực hiện việc phân nhóm cấp cao nhất bằng cách truy cập, nhưng tại một thời điểm nào đó, tôi không biết khi nào, nó không hoạt động tốt như ở trên. Ví dụ: trong C ++ / CLI (hiện tại tôi buộc phải sử dụng :-() bạn có thể thực hiện việc này, điều này làm rối tung việc phân nhóm theo truy cập:

public: property int SomeProperty
{
private: void set (int value) { ... }
public: int get () { ... }
}

Câu trả lời ngoài lề: Tôi không, ít nhất là khi nói đến C #. Giữa Visual Studio và R # tôi có thể điều hướng một cách kỳ diệu đến bất kỳ thành viên hoặc triển khai nào để không bị ám ảnh về nội dung này; chỉ cần bắt đầu nhập nơi con trỏ là.

Giống như Wyatt và một vài câu trả lời khác, tôi cũng thường tránh sử dụng các vùng. Khu vực có một mục đích; để ẩn mã bạn không muốn phải xem. Nếu bạn có rất nhiều mã trong một lớp mà bạn không muốn xem, và do đó bạn cần rất nhiều vùng để cho phép bạn thu gọn mã đã nói, thì có lẽ bạn có quá nhiều mã trong lớp. ReSharper không tôn trọng các khu vực khi quyết định nơi đặt mã mới, trừ khi nó tạo ra khu vực (mà nó thực hiện cho việc triển khai giao diện).

Việc sử dụng các vùng mà tôi thấy chấp nhận được là ẩn mã "xấu không thể tránh khỏi"; mã liên quan đến các chi tiết triển khai cụ thể không thể được kiến ​​trúc nội bộ theo các tiêu chuẩn hiện hành. Đây thường là mã tiên tiến, bí truyền thường không bị nhầm lẫn bởi các lập trình viên cơ sở trung bình một khi đã viết. Đây là những thứ như:

• Một số triển khai giao diện tích hợp nhất định (IDis Dùng một lần, IConvertible, đôi khi IEnumerable hoặc IComparable khi chúng yêu cầu triển khai chung và không chung)
• P / Gọi ra bên ngoài và các cấu trúc liên quan.
• Hoàn thiện / hủy bỏ (thường đi với IDis Dùng)
• Móc vào bộ nhớ / con trỏ / mã "không an toàn" không được quản lý.