Định dạng mã: Bố trí các hàm dựa trên phân cấp cuộc gọi trong một tệp lớp?

Một gợi ý từ "Mã sạch" của Bob Martin khiến tôi phải vò đầu bứt tai .. "Nếu một khi chức năng gọi khác, họ nên đóng theo chiều dọc và người gọi nên ở trên callee"

Cho đến nay, tôi đã ít nhiều bám sát các hướng dẫn .Net, nhóm thành viên nhóm nào theo loại (thuộc tính, bộ đệm, chức năng) và mức độ hiển thị (công khai / bảo vệ / riêng tư). Đầu tiên có vẻ như rắc rối .. nhưng nó "chỉ có thể hoạt động". Cá nhân tôi đã gặp trường hợp tôi thích cách bố trí này - dễ dàng đi sâu hơn khi bạn vào đúng chuỗi cuộc gọi.

Ý tưởng đằng sau tiền boa có vẻ hợp lý nhưng các kịch bản khác như "hãy để tôi nhìn vào giao diện công cộng của lớp này" có thể trở nên tồi tệ hơn. Có lẽ chú Bob đang ngân hàng trên các lớp học nhỏ và hỗ trợ IDE để xem các loại ...

Có ai đã thử điều này trong một thời gian dài?

Cập nhật: Có vẻ như một đoạn mã theo thứ tự

class SomeType()
{
  /// fields, ctors, et. all
  public void Method1()   { // calls HelperMethod1 and HelperMethod2 }
  private void HelperMethod1 { // calls HelperMethod3 }
  private void HelperMethod3 {}
  private void HelperMethod2 {}

  public void Method2 () { // and so on... }

}

Tôi có thể đi ra ngoài ở đây, nhưng tôi tự hỏi liệu công cụ bạn sử dụng có ảnh hưởng đến điều này không. Tôi đang đề cập đến trình soạn thảo văn bản so với quyết định IDE mà các nhà phát triển phải đưa ra.

Trong một IDE, bạn có nhiều chức năng hơn để xem các tệp nguồn. Thông thường, bạn có thể nhận được một danh sách các phương thức được sắp xếp theo thứ tự abc, theo mức độ hiển thị hoặc thậm chí loại trả về trong một thanh bên. Bạn cũng có thể chuyển sang một phương thức nếu bạn có cách sử dụng nó. Bạn cũng có thể tạo cây gọi cho các phương thức và đi sâu vào. Bạn cũng thường có một lệnh find mạnh mẽ có thể hỗ trợ các biểu thức thông thường. Trong tình huống này, thứ tự các phương thức mà bạn tạo thực sự không quan trọng vì bạn có các chế độ xem khác với mã nguồn có sẵn.

Trong trình chỉnh sửa văn bản, bạn thường không có các tính năng này - gần nhất mà bạn có thể tìm thấy / thay thế mạnh mẽ. Ở đây, bạn sẽ muốn chú ý nhiều hơn đến cấu trúc tệp của mình vì có thể khó điều hướng hơn. Bạn muốn giảm thiểu thời gian di chuyển xung quanh tệp để tìm thấy những gì bạn đang tìm kiếm và một thứ tự các phương pháp hợp lý và hợp lý có thể giúp ích.

Vấn đề là những thứ được gọi là ít thú vị hơn so với gọi những thứ. Phương thức càng gọi các phương thức khác thì phương thức đó càng là một phần của API bên ngoài của đối tượng (trái ngược với việc là một chi tiết triển khai). Điều đó có nghĩa là API bên ngoài của lớp - các phương thức công khai, nếu ngôn ngữ của bạn hỗ trợ khái niệm đó - sẽ tự nhiên "muốn" ở đầu tệp, giúp tìm các phương thức đó dễ dàng hơn. Ngược lại, các hàm trợ giúp và như vậy sẽ "muốn" ở dưới cùng của tệp.

(Tôi đang giải thích khái niệm này, không đánh giá hiệu quả của nó.)

Nếu trong thời gian dài, bạn có nghĩa là hơn một vài ngày? Sau đó,
Một vài năm trước tôi đã bắt đầu làm điều này trên một số mã mới, và từ từ lái xe điên cuồng, cho đến khi tôi dừng lại.

Sở thích cá nhân của tôi để bố trí các lớp học là

class MyClass
{
    // static fields
    // fields
    // constructors
    // properties
    // methods
} 

Nhưng đó không phải là tôn giáo, tài sản và phương pháp có thể trộn lẫn với nhau. Khả năng hiển thị không đi vào nó (Tôi không nhóm theo công khai / được bảo vệ / riêng tư)

Chúng tôi có một chàng trai ở đây trong văn phòng giữ một cấu trúc chặt chẽ về mọi thứ trong một tệp lớp, với mọi thứ được nhóm lại trong các nhóm chính và các nhóm phụ, tất cả đều được lồng vào nhau một cách độc đáo. . . Tôi phải thừa nhận tôi nghĩ rằng các khu vực là công việc của Satan, họ lái tôi đi vòng quanh feckin.

Mỗi khi tôi mở một trong những lớp học của anh ấy, tôi sẽ chết một chút bên trong :(