Tôi có nên tạo phương thức tĩnh hoặc siêu lớp trừu tượng

Question

Tôi đang cố gắng cấu trúc lại dự án trong đó có cùng phương thức được trải rộng trên nhiều lớp khác nhau. Để giảm trùng lặp mã, tôi có nên chuyển mã chung vào một siêu lớp trừu tượng hay tôi nên đặt nó trong một phương thức tĩnh trong một lớp tiện ích?

CHỈNH SỬA Một số phương pháp dành cho nội dung chung mà tôi cho rằng có thể được tạo thành tĩnh. Trong khi có những người khác đề cập đến các thuộc tính của lớp, trong trường hợp đó tôi nghĩ rằng nó có ý nghĩa hơn để biến nó thành một lớp siêu trừu tượng.

Answer 1

Nếu nó không sử dụng bất kỳ thành viên lớp nào bạn có thể làm điều đó tĩnh!

Nhưng bạn nên làm điều đó trong lớp trừu tượng hoặc lớp mẹ

Answer 2

Một điểm khác cần xem xét có thể là loại công việc mà các chức năng này thực hiện. Nếu đó là rải rác, bạn nên tạo một lớp facade/helper/util với các phương thức tĩnh.

Answer 3

Tùy thuộc vào mã của bạn đang làm gì. Chúng có phải là phương pháp tiện ích không? Chúng có phải là các phương pháp lớp cụ thể/chuyên biệt không? Đây có phải là ứng dụng đa luồng nặng không?

Hãy nhớ rằng nếu bạn đặt chúng tĩnh và ứng dụng của bạn đa luồng, bạn sẽ phải bảo vệ chúng bằng khóa. Điều này, đến lượt nó, làm giảm sự tương tranh. Trong trường hợp này, tùy thuộc vào số lượng chủ đề gọi cùng một đoạn mã, bạn có thể xem xét di chuyển nó (mã) thành một lớp siêu.

Answer 4

Vâng, tôi tuân thủ quy tắc: Không sử dụng lớp cơ sở để xóa trùng lặp mã, sử dụng lớp tiện ích.

Để kế thừa, hãy đặt câu hỏi cho chính mình: Mối quan hệ Is-A có tồn tại không?

Một quy tắc, mà hầu hết các lần là đúng, là: thích thành phần trên thừa kế

sử dụng lớp tiện ích tĩnh là không cấu thành sự thật nhưng nó có thể được gọi là một nguồn gốc của nó.

Áp dụng các quy tắc này cho secenrios của bạn và đưa ra quyết định giữ trong tâm trí bảo trì và khả năng mở rộng. Tuy nhiên nó sẽ là tốt nếu bạn có thể thêm chi tiết hơn để quesiton của bạn.

Answer 5

Nếu các phương thức sử dụng nhiều trường hoặc phương thức của lớp, chúng không được tĩnh. Nếu chúng là thứ mà lớp con có thể muốn sửa đổi chúng không nên tĩnh. Nếu các phương thức phải là một phần của Giao diện, chúng không thể tĩnh.

Nếu không, đó là cuộc gọi của bạn và có thể bạn sẽ thay đổi quyết định sau này. :-)

Answer 6

Khi những người khác đã đề cập câu trả lời cho điều này phụ thuộc vào ngữ cảnh của sự cố và mã trùng lặp.

Một số điều cần xem xét

• Liệu mã trùng lặp biến những thể hiện của đối tượng. Trong trường hợp này, phương thức được bảo vệ trong lớp trừu tượng chung
• Thay vì lớp tiện ích tĩnh xem xét một singleton, các phương thức tĩnh có thể có vấn đề đối với thử nghiệm đơn vị thuần túy mặc dù các khuôn khổ thử nghiệm đang ngày càng tốt hơn.
• Thừa kế có thể khó khăn để có được quyền, suy nghĩ về nếu các đối tượng này từ các lớp khác nhau có thực sự liên quan và yêu cầu một số OO lại bao thanh toán? hoặc là chúng phân tách các phần của logic miền xảy ra để yêu cầu các bit tương tự của mã.

Answer 7

Thoạt nhìn, tôi sẽ nói rằng sẽ tốt hơn nếu làm cho mã chung là phương thức tĩnh công khai trong lớp công khai. Điều này sẽ làm phương pháp hữu ích cho bất kỳ lớp học chỉ bằng cách sử dụng

UtilityClassName.methodName(); 

này là tốt hơn sau đó làm cho nó một phương pháp cụ thể trong một siêu lớp trừu tượng bởi vì khi đó bạn sẽ luôn luôn cần phải mở rộng siêu lớp này trong tất cả các lớp nơi bạn muốn sử dụng một phương pháp duy nhất này.

Nhưng bây giờ, như bạn đã nói rằng hành vi của phương pháp phụ thuộc vào một số biến. Bây giờ, nếu nó phụ thuộc vào các biến cá thể của các lớp khác nhau, thì tốt hơn hãy thêm phương thức này vào một giao diện và cho phép tất cả các lớp của bạn triển khai thực hiện giao diện này và có thực hiện riêng của chúng giống nhau.

Nhưng một lần nữa nếu các biến này là giá trị không đổi, thì có các giá trị không đổi này trong một giao diện. Thực hiện các giao diện này trong lớp tiện ích của bạn. Và một lần nữa làm cho nó trở thành một phương thức tĩnh trong lớp tiện ích sẽ trực tiếp sử dụng các hằng số này.

Ví dụ: Hãy xem xét foll. mã chung của khu vực trả về của một vòng kết nối.

public interface TwoDimensional{ 
     double PI = 3.14; 
    } 

    public class MyUtility implements TwoDimensional{ 
     public static double getCircleArea(double radius){ 
      return PI*radius*radius; 
     } 
    } 

Ở đây, bạn có thể thấy rằng phương pháp getCircleArea() phụ thuộc vào bán kính đó sẽ khác nhau cho các lớp học khác nhau nhưng tôi vẫn có thể vượt qua giá trị này vào phương thức tĩnh của lớp myUtility.