2012-08-23 59 views
5

Đến bây giờ lớp trung bình của tôi chứa khoảng 500 dòng mã và khoảng 50 phương pháp. IDE là Eclipse, nơi tôi đã chuyển “Lưu hành động” để các phương thức được sắp xếp theo thứ tự bảng chữ cái, phương pháp công khai đầu tiên và sau đó là các phương thức riêng tư. Để tìm bất kỳ phương pháp cụ thể trong mã tôi sử dụng "Quick Outline". Nếu cần, “Mở Hệ thống phân cấp cuộc gọi” sẽ hiển thị chuỗi các phương thức mà chúng được gọi là từng phương pháp.Làm thế nào để bạn tổ chức mã nguồn lớp trong Java?

Cách tiếp cận này cho phép ưu điểm sau:

  • tôi có thể bắt đầu gõ phương pháp mới mà không nghĩ đến nơi để đặt nó trong các mã, bởi vì sau khi lưu nó sẽ được đặt bởi Eclipse để chiếm vị trí tự động.
  • tôi luôn luôn tìm các phương pháp công cộng ở phần trên của mã (không cần phải tìm kiếm cả lớp cho họ)

Tuy nhiên có một số nhược điểm:

Khi refactoring phương pháp lớn thành nhỏ hơn tôi không hài lòng lắm vì các phương thức riêng tư mới được đặt trong các phần mã khác nhau và do đó hơi khó tuân theo khái niệm mã. Để tránh điều đó, tôi đặt tên chúng theo một cách kỳ lạ để giữ chúng gần nhau, ví dụ: showPageFirst(), showPageSecond() thay vì showFirstPage(), showSecondPage().

Có thể có một số phương pháp tiếp cận tốt hơn không?

+0

Thanh toán http://www.amazon.com/Design-Patterns-Java -Software-Series/dp/0321333020 nó sẽ giúp bạn viết phần mềm dễ dàng hơn để duy trì và chia sẻ với người khác –

Trả lời

3

Vâng, đặt tên phương pháp của bạn để họ sẽ dễ dàng hơn để phát hiện trong IDE của bạn thực sự là không tốt. Tên của họ nên phản ánh những gì họ làm, không có gì hơn.

Như một câu trả lời cho câu hỏi của bạn, có lẽ điều tốt nhất cần làm là chia lớp thành nhiều lớp và tách nhóm các phương thức có điểm chung trong mỗi lớp như vậy. Ví dụ, nếu bạn có

public void largeMethodThatDoesSomething() { 
//do A 
//do B 
//do C 
} 

mà sau đó bạn đã refactored ví dụ rằng:

public void largeMethodThatDoesSomething() { 
doA(); 
doB(); 
doC(); 
} 

private void doA() {}; 
private void doB() {}; 
private void doC() {}; 

bạn có thể tạo ra một lớp được gọi là SomethingDoer nơi bạn đặt tất cả những 4 metods và sau đó sử dụng một ví dụ về điều đó lớp học trong lớp học ban đầu của bạn.

+0

Nó không phải là tốt để tăng số lượng các lớp học trong pro ject? Tôi nhớ rằng trong Hướng dẫn Java, họ đã cảnh báo không tăng số lượng các lớp không kiểm soát được vì nó có thể tăng thời gian khởi động? http://docs.oracle.com/javase/tutorial/uiswing/events/generalrules.html#innerClasses – Aleksey

+0

Vâng, tôi biết ý của bạn là gì, tôi cũng đã xuống đường. Thậm chí có cả trang Mẹo về hiệu suất để phát triển Android (sử dụng Java), mà đồng bằng ole 'cho bạn biết không chỉ để tạo ra vài lớp mà còn để tránh các phương pháp ủng hộ các trường công khai, tránh thừa kế và gọi đa hình vì bổ sung thêm nano giây chậm trễ và một vòng lặp trò chơi rất quan trọng. Tuy nhiên đi đến cực đoan với điều đó sẽ dẫn đến khó sử dụng và khó duy trì mã. Hãy thử mã hóa đúng cách và gọn gàng với các lớp riêng biệt theo các phương thức theo nhu cầu kinh doanh của chương trình của bạn ... –

+0

... sau đó nếu cần, hãy lập hồ sơ ứng dụng của bạn, xem mã có tạo cổ chai hiệu suất không, và cố gắng chỉ tối ưu hóa phần đó bằng cách nó kém thẩm mỹ hơn nhưng hiệu suất thân thiện hơn. Tôi tin tưởng, mã hóa từ đầu với hiệu suất ONLY trong tâm trí và không có gì khác sẽ giúp bạn gặp rắc rối. –

1

Sắp xếp cách bạn mô tả âm thanh tốt hơn 99% mã Java mà tôi đã thấy cho đến thời điểm này. Tuy nhiên, ở phía bên kia, hãy chắc chắn rằng các lớp học của bạn không phát triển quá nhiều và phương pháp không phải là rất lớn.

Lớp học thường nên được ít hơn 1000 dòng và các phương pháp ít hơn 150.

3

Đừng lo lắng về việc sắp xếp vật lý các phương pháp của bạn bên trong lớp, nếu bạn không thể nhìn thấy nó chỉ cần sử dụng Ctrl-O và bắt đầu gõ tên phương thức và bạn sẽ nhảy thẳng đến nó.

Có tên phương pháp tự mô tả dẫn đến mã dễ bảo trì hơn so với đặt tên giả tạo để giữ chúng theo thứ tự bảng chữ cái.

Gợi ý: tìm hiểu các phím tắt của bạn và bạn sẽ cải thiện năng suất của mình

4

Sắp xếp mã cho đối tượng của nó.Ví dụ: một lớp trong thư viện có thể có các đối tượng này:

  1. Ứng dụng khách API muốn biết thêm chi tiết về cách thức hoạt động của phương thức công khai.
  2. Một người bảo trì muốn tìm phương pháp thích hợp để thực hiện một thay đổi nhỏ.
  3. Người bảo trì nghiêm túc hơn, những người muốn thực hiện tái cấu trúc hoặc thêm chức năng quan trọng.

Đối với khách hàng sử dụng mã nguồn, bạn muốn giới thiệu các khái niệm cốt lõi. Đầu tiên chúng ta có một chú thích doc lớp bao gồm một bảng thuật ngữ các thuật ngữ quan trọng và các ví dụ sử dụng. Sau đó, chúng tôi có mã liên quan đến một thuật ngữ, sau đó những người liên quan đến một thuật ngữ khác, sau đó những người liên quan đến một thứ ba.

Đối với người bảo trì, bất kỳ cặp phương pháp nào có khả năng phải thay đổi cùng nhau phải ở gần. Một phương thức công khai và helper riêng của nó và bất kỳ hằng số nào liên quan đến nó chỉ nên hiển thị cùng nhau.

Cả hai nhóm người dùng này đều được hỗ trợ bằng cách nhóm các thành viên nhóm thành các phần hợp lý được lập thành tài liệu riêng.

Ví dụ, một lớp sưu tập có thể có một số mối quan tâm chủ yếu trực giao mà không thể dễ dàng được chia ra thành các lớp riêng biệt nhưng có thể được chia thành các phần riêng biệt.

  1. Đột biến
  2. Accessors
  3. Iteration
  4. serializing và toString
  5. bình đẳng, so sánh, băm
Các vấn đề liên quan