Giới hạn số lượng của một phương thức lớp là gì?


22

Trong các cuốn sách thiết kế khác nhau mà tôi đọc, đôi khi nhấn mạnh vào số lượng phương thức mà một lớp phải có (ví dụ như sử dụng ngôn ngữ OO, như java hoặc C #). Thông thường các ví dụ được báo cáo trong những cuốn sách đó rất gọn gàng và đơn giản, nhưng hiếm khi chúng bao gồm một trường hợp "nghiêm trọng" hoặc phức tạp.
Tuy nhiên, phạm vi dường như là giữa 5 và 8.

Trong một dự án tôi đã phát triển một lớp "Ghi chú", với attribuse là các thuộc tính: Title, Desctiption, CreateDate, v.v.
Sau đó, một số phương thức cơ bản như: getRelations (nếu ghi chú được gán cho các tài liệu khác nhau), getExpiryDate, ect.

Tuy nhiên, tiến hành phát triển ứng dụng, cần nhiều chức năng hơn và do đó, nhiều phương pháp hơn.

Tôi biết rằng một lớp càng ít phương thức, nó càng được ghép lỏng lẻo. Đó thực sự là một lợi thế tốt về mặt mô-đun và tái sử dụng, cộng với dễ dàng chỉnh sửa hơn.
Nhân tiện, nếu trong ngữ cảnh của chúng ta không có nhu cầu (hoặc thậm chí là ý nghĩa) để tạo các lớp con và tất cả các hàm cần thiết có liên quan đến lớp đó, chúng ta có thể đính kèm thêm bao nhiêu phương thức?

Tôi đồng ý rằng có hơn 15 phương thức, sau đó có thể cần phải thiết kế lại một chút.
Nhưng ngay cả trong trường hợp đó, nếu xóa một số phương thức hoặc kế thừa không phải là một lựa chọn, đó sẽ là cách thích hợp?


3
Con người dường như có một phạm vi quên sẵn có. Khi bạn vượt qua bảy lựa chọn, một vài lựa chọn đầu tiên sẽ bị lãng quên. Vì vậy, đừng cung cấp cho mọi người nhiều hơn 7 tùy chọn trên mỗi giao diện.
Martin York

+ 1 @ Martin- 7 + hoặc- 2
Morgan Herlocker

Giới hạn này chỉ dành cho bộ nhớ ngắn hạn. Nếu không, làm thế nào chúng ta có thể nhớ tất cả những chữ cái và từ khác nhau? Nghiêm túc mà nói, nếu lớp học sẽ được sử dụng nhiều, bạn có thể nghĩ nó là ngôn ngữ nhỏ và có nhiều phương pháp bạn cần để diễn đạt bất cứ điều gì bạn phải làm với nó.
artem


Câu trả lời:


30

Có nhiều phương pháp như bạn cần. Tôi sẽ cố gắng duy trì số lượng phương thức công khai theo quy tắc 5-8 đó nếu có thể. Thành thật mà nói, hầu hết mọi người đều có vấn đề ngược lại, nơi họ có những phương pháp siêu điên cần được chia nhỏ hơn chứ không phải ít hơn. Nó thực sự không quan trọng bạn có bao nhiêu phương pháp trợ giúp riêng tư. Trong thực tế, nếu bạn ở dưới 8 phương thức trong Java, bạn có thể đạt đến giới hạn với một lớp chỉ có hàm tạo, toString và getter / setter cho 3 thuộc tính ... không chính xác là một lớp mạnh. Điểm mấu chốt là, đừng lo lắng về việc lớp học của bạn có bao nhiêu phương thức. Lo lắng về việc đảm bảo rằng lớp học của bạn không có những mối quan tâm không liên quan và rằng bạn có một giao diện công cộng hợp lý có các phương thức dễ hiểu.


Đúng, nhưng nếu nó là một lớp tiện ích, tối đa 10-15 là tốt.
Sid

1
@SidCool - Tôi không nói rằng tôi không sử dụng chúng bao giờ, nhưng các lớp tiện ích không thực sự là một cách thực hành tốt nhất để bắt đầu. Họ thường chỉ là một lớp thần nhỏ đặt một loạt các mối quan tâm không liên quan với nhau. Với ý nghĩ đó, một lớp tiện ích thực sự không nên tồn tại, ít hơn nhiều với 15 phương thức.
Morgan Herlocker

1
Lớp "Ghi chú" của tôi không phải là lớp tiện ích. Nó đại diện cho một đối tượng kinh doanh (một ghi chú có thể thêm nhận xét và mô tả vào tài liệu). Tuy nhiên, tôi đồng ý với mã sắt về sự nguy hiểm của các lớp "tiện ích". Họ đến giúp đỡ khi chúng tôi vội vàng với thời hạn giao hàng, nhưng tôi nghĩ thường có giải pháp / thiết kế tốt hơn cho họ.
Francesco

13

Câu trả lời thực sự đơn giản: Đặt mọi thứ trong một lớp thuộc về trách nhiệm của nó, nhưng hãy cẩn thận khi giao trách nhiệm.

Đôi khi một lớp lớn là tổng hợp của các lớp nhỏ hơn với các trách nhiệm khác nhau.

Nói chung, tôi cố gắng phân chia các trách nhiệm thành các lớp nhỏ hơn khi lớp trở nên khó sử dụng hoặc trong bảo trì. Tôi hiếm khi có các lớp dài hơn 500 dòng. Các lớp lớn nhất của tôi có xấp xỉ 1,5k locs.

Bạn chỉ đơn giản là không thể nêu một quy tắc chung như "một lớp nên có giữa các phương thức n và m".


8

Không có lý do (trong thiết kế OO) chỉ có rất nhiều phương pháp. Cũng không đúng khi một lớp có ít phương thức được phân tách tốt hơn.

Nhìn vào lớp java.lang.String chẳng hạn. Rất nhiều phương thức, bởi vì có rất nhiều thứ người ta có thể làm với một chuỗi. Tuy nhiên không được kết hợp mạnh mẽ.

Tôi tự hỏi tại sao một con số ma thuật như 15 có thể tách rời thiết kế tốt và xấu. Không, nó không dễ dàng như vậy.


Tôi đồng ý, con số 15 chỉ là một xấp xỉ xuất phát từ việc đọc những cuốn sách thiết kế đó (như "Hoàn thành mã" của Steven McConnell, chẳng hạn). Thật vậy, lớp String có một phép màu của các phương thức và tất cả được thực hiện cho cùng một thực thể.
Francesco

@Luca: Vấn đề với một số trong những cuốn sách đó là các ví dụ thường bị chiếm đoạt và do đó nhỏ hơn nhiều ví dụ trong thế giới thực.
Thất vọngWithFormsDesigner

Chính xác ... có lẽ là để làm cho các khái niệm rõ ràng hơn cho hầu hết và để mở rộng cơ sở tiềm năng của người mua quá ...
Francesco

Tôi muốn thấy bất kỳ loại DataGrid hoặc thậm chí kiểm soát UI chỉ với 15 phương thức. Nếu bạn chia những lớp đó thành những lớp nhỏ hơn thì giao diện sẽ trở thành một cơn ác mộng.
Chim ưng

6

Trong PMD, hành vi mặc định của quy tắc TooManyMethods là xác định và gắn cờ các lớp với 10 phương thức trở lên là lỗi tiềm ẩn. Đây chỉ là một con số tùy ý. Nó dễ dàng thay đổi trong một cấu hình. Bất kể con số này là bao nhiêu, nó chỉ là một lá cờ để nhà phát triển nhìn vào một lớp và xem nếu có vấn đề, không phải là có vấn đề với nó.

Một cái gì đó cụ thể hơn một chút có thể là quy tắc 7 cộng / trừ 2 . Điều này nói lên rằng tâm trí con người có thể nắm giữ và thấu hiểu từ 5 đến 9 "đối tượng" trong bộ nhớ. Khi đọc một lớp cụ thể, các đối tượng rất có thể là các phương thức và các trường tạo nên lớp đó. Tuy nhiên, các lớp học thường xuyên có hơn 9 lĩnh vực và phương pháp, ngay cả khi bạn không được tính accessors, mutators và bất kỳ hoạt động tiêu chuẩn (ví dụ toString(), hashCode()equals()trong Java).

Các biện pháp phù hợp nhất sẽ là fan-in và fan-out và thảo luận về khớp nốisự gắn kết . Các nguyên tắc trách nhiệm duy nhấttách mối quan tâm cần được áp dụng - một lớp học nên làm hoặc đại diện cho một điều và một điều một mình. Những cách này tốt hơn nhiều so với việc cố gắng gán số cho số phương thức tối đa / tối thiểu khi đánh giá một thiết kế hoặc triển khai.


+1 - quy tắc 7 + -2 là quy tắc sống theo nơi có thể sử dụng được.
Morgan Herlocker
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.