Cách tiếp cận tốt nhất để đặt tên lớp là gì?


92

Tìm ra những cái tên hay, chính xác cho các lớp nổi tiếng là khó. Được thực hiện đúng, nó làm cho mã tự lập tài liệu hơn và cung cấp vốn từ vựng để lập luận về mã ở mức độ trừu tượng cao hơn.

Các lớp triển khai một mẫu thiết kế cụ thể có thể được đặt tên dựa trên tên mẫu nổi tiếng (ví dụ: FooFactory, FooFacade) và các lớp trực tiếp mô hình hóa khái niệm miền có thể lấy tên của chúng từ miền vấn đề, nhưng còn các lớp khác thì sao? Có điều gì giống như từ điển đồng nghĩa của một lập trình viên mà tôi có thể tìm đến khi thiếu cảm hứng và muốn tránh sử dụng các tên lớp chung chung (như FooHandler, FooProcessor, FooUtils và FooManager) không?


6
Đây là một câu hỏi tuyệt vời! Đóng nó là IMHO không hợp lý, tốt hơn là nên di chuyển trang web của lập trình viên.
Timofey

1
Tôi đồng ý, nên mở lại hoặc chuyển
ftl


Tôi đã thấy rất nhiều câu hỏi tuyệt vời này "đóng bởi casperOne". Có lẽ anh ta có thể phục vụ như một người xóa tại Wikipedia?
Perlator

Câu trả lời:


59

Tôi sẽ trích dẫn một số đoạn trong Mô hình triển khai của Kent Beck:

Tên lớp đơn giản

"[...] Những cái tên nên ngắn gọn và mạnh mẽ. Tuy nhiên, để làm cho tên chính xác đôi khi dường như cần nhiều từ. Một cách thoát khỏi tình thế khó xử này là chọn một phép ẩn dụ mạnh mẽ cho phép tính. Với một phép ẩn dụ trong tâm trí, thậm chí các từ đơn lẻ mang đến cho chúng một mạng lưới liên kết, kết nối và hàm ý phong phú. Ví dụ: trong khung vẽ HotDraw, tên đầu tiên của tôi cho một đối tượng trong bản vẽ là DrawingObject . Ward Cunningham đi cùng với phép ẩn dụ kiểu chữ: một bản vẽ giống như một trang in, có bố cục. Các mục đồ họa trên một trang là các số liệu, do đó, lớp trở thành Hình . Trong ngữ cảnh của phép ẩn dụ, Hình đồng thời ngắn hơn, phong phú hơn và chính xác hơn so với DrawingObject . "

Tên lớp con đủ điều kiện

"Tên của các lớp con có hai công việc. Chúng cần giao tiếp với nhau rằng chúng giống lớp nào và chúng khác nhau như thế nào. [...] Không giống như tên gốc của cấu trúc phân cấp, tên lớp con không được sử dụng thường xuyên trong cuộc trò chuyện, để chúng có thể diễn đạt với chi phí ngắn gọn. [...]

Đặt tên đơn giản cho các lớp con đóng vai trò là gốc rễ của phân cấp. Ví dụ, HotDraw có một Class Handle trình bày các thao tác chỉnh sửa hình khi một hình được chọn. Nó được gọi đơn giản là Xử lý mặc dù mở rộng Hình . Có cả một họ các tay cầm và chúng thích hợp nhất có các tên như StretchyHandleTransparencyHandle . Bởi vì Handle là gốc của hệ thống phân cấp của chính nó, nó xứng đáng là một tên lớp cha đơn giản hơn một tên lớp con đủ điều kiện.

Một vấn đề khác trong cách đặt tên lớp con là cấu trúc phân cấp nhiều cấp. [...] Thay vì thêm một cách mù quáng các bổ ngữ vào lớp cha ngay lập tức, hãy nghĩ về cái tên từ quan điểm của người đọc. Bạn ấy cần biết lớp này như thế nào? Sử dụng lớp cha đó làm cơ sở cho tên lớp con. "

Giao diện

Hai kiểu đặt tên giao diện phụ thuộc vào cách bạn nghĩ về các giao diện. Các giao diện dưới dạng các lớp không có triển khai nên được đặt tên như thể chúng là các lớp ( Tên lớp đơn giản , Tên lớp con đủ điều kiện ). Một vấn đề với kiểu đặt tên này là những cái tên hay được sử dụng hết trước khi bạn chuyển sang đặt tên cho các lớp. Một giao diện được gọi là Tệp cần một lớp triển khai có tên là ActualFile , ConcreteFile hoặc (yuck!) FileImpl(vừa là hậu tố vừa là chữ viết tắt). Nói chung, giao tiếp cho dù một người đang xử lý một đối tượng cụ thể hay trừu tượng là quan trọng, liệu đối tượng trừu tượng được thực hiện như một giao diện hay một lớp cha ít quan trọng hơn. Việc trì hoãn sự phân biệt giữa các giao diện và lớp cha> được hỗ trợ bởi phong cách đặt tên này, giúp bạn có thể tự do thay đổi ý định sau này nếu điều đó> trở nên cần thiết.

Đôi khi, việc đặt tên cho các lớp cụ thể chỉ đơn giản là quan trọng đối với giao tiếp hơn là ẩn việc sử dụng các giao diện. Trong trường hợp này, các tên giao diện tiền tố bằng “I”. Nếu giao diện được gọi là IFile , thì lớp có thể được gọi đơn giản là Tệp .

Để thảo luận chi tiết hơn, hãy mua cuốn sách! Nó đáng giá! :)


1
"Đôi khi, việc đặt tên các lớp cụ thể chỉ đơn giản là quan trọng đối với giao tiếp hơn là ẩn việc sử dụng các giao diện. Trong trường hợp này, đặt tên giao diện tiền tố bằng" I ". Nếu giao diện được gọi là IFile, thì lớp có thể được gọi đơn giản là Tệp." Thật là buồn cười, bởi vì trong cuốn sách Clean Code của Robert C. Martin, tôi phát hiện ra rằng chúng tôi muốn đặt tên các triển khai là FileImpl, hơn là đặt tên giao diện như IFile, bởi vì chúng tôi không muốn khách hàng biết rằng chúng tôi đang phục vụ họ giao diện. Và trong cuốn sách ^ có trích dẫn từ cuốn sách mà bạn đang đề cập đến :)
Cristian Ciobotea

38

Luôn sử dụng MyClassA, MyClassB - Nó cho phép sắp xếp alpha đẹp mắt ..

Tôi đùa đấy!

Đây là một câu hỏi hay, và là điều mà tôi đã trải qua cách đây không lâu. Tôi đang tổ chức lại cơ sở mã của mình tại nơi làm việc và gặp vấn đề về nơi đặt cái gì và gọi nó là gì ..

Các thực vấn đề?

Tôi đã có các lớp học làm quá nhiều. Nếu bạn cố gắng tuân thủ nguyên tắc trách nhiệm duy nhất, nó sẽ làm cho mọi thứ trở nên đẹp hơn nhiều .. Thay vì một lớp PrintHandler nguyên khối , bạn có thể chia nhỏ nó thành PageHandler , PageFormatter (v.v.) và sau đó có một lớp Máy in chính. mang tất cả lại với nhau.

Trong lần tổ chức lại của mình, tôi đã mất thời gian, nhưng cuối cùng tôi đã binning rất nhiều mã trùng lặp, làm cho cơ sở mã của tôi logic hơn nhiều và học được rất nhiều điều khi phải suy nghĩ trước khi ném một phương thức bổ sung vào một lớp: D

Tuy nhiên, tôi không khuyên bạn nên đặt những thứ như tên mẫu vào tên lớp. Giao diện các lớp phải làm cho điều đó trở nên rõ ràng (như ẩn hàm tạo cho một singleton). Không có gì sai với tên chung, nếu lớp đang phục vụ một mục đích chung.

Chúc may mắn!


Đồng ý với việc không đặt tên mẫu vào tên lớp. Điều gì sẽ xảy ra nếu mẫu thay đổi sau đó khi việc triển khai thay đổi?
thegreendroid

2
Tôi muốn đặt một tên của mô hình trong một cái tên. Tại sao? Bởi vì nếu tôi phải xem xét chi tiết triển khai (như hàm tạo riêng) để tìm ra rằng đó là một singleton, điều đó làm tôi chậm lại với tư cách là một người đọc và tùy thuộc vào trình độ kỹ năng của tôi, tôi có thể không hiểu rằng đó thực sự là một phần của lớp. của mẫu chung. Singleton và phương thức khởi tạo riêng là một ví dụ đáng ngờ, nhưng đối với các mẫu phức tạp hơn (Khách truy cập, Bộ điều hợp, v.v.) thì nó trở nên khá phức tạp. Nếu những thay đổi mô hình, các chaces là rằng những lớp học sẽ không tồn tại nữa ...
dragan.stepanovic

28

Bài nói tuyệt vời của Josh Bloch về thiết kế API tốt có một vài lời khuyên hữu ích:

  • Các lớp nên làm một việc và làm tốt điều đó.
  • Nếu một lớp khó đặt tên hoặc khó giải thích thì có lẽ nó không tuân theo lời khuyên trong gạch đầu dòng trước.
  • Tên lớp sẽ truyền đạt ngay lập tức lớp đó là gì.
  • Tên tốt tạo ra thiết kế tốt.

Nếu vấn đề của bạn là đặt tên cho các lớp nội bộ tiếp xúc, có lẽ bạn nên hợp nhất chúng thành một lớp lớn hơn.

Nếu vấn đề của bạn là đặt tên cho một lớp đang thực hiện nhiều nội dung khác nhau, bạn nên cân nhắc việc chia nó thành nhiều lớp.

Nếu đó là lời khuyên tốt cho một API công khai thì nó không thể gây hại cho bất kỳ lớp nào khác.


1
liên kết video trên youtube youtube.com/watch?v=aAb7hSCtvGw
Andrew Harry

12

Nếu bạn đang mắc kẹt với một cái tên, đôi khi chỉ cần đặt cho nó bất kỳ cái tên hợp lý nào với cam kết sửa đổi nó sau đó là một chiến lược tốt.

Đừng để bị liệt tên. Đúng vậy, tên rất quan trọng nhưng chúng không đủ quan trọng để lãng phí một lượng lớn thời gian. Nếu bạn không thể nghĩ ra một cái tên hay trong 10 phút, hãy tiếp tục.


9

Nếu một cái tên hay không xuất hiện trong tâm trí, tôi có lẽ sẽ đặt câu hỏi liệu có một vấn đề sâu xa hơn - liệu lớp học có phục vụ mục đích tốt không? Nếu có, việc đặt tên cho nó phải khá đơn giản.


3

Nếu "FooProcessor" của bạn thực sự xử lý foos, thì đừng ngần ngại đặt cho nó cái tên đó chỉ vì bạn đã có BarProcessor, BazProcessor, v.v. Khi nghi ngờ, rõ ràng là tốt nhất. Các nhà phát triển khác phải đọc mã của bạn có thể không sử dụng cùng một từ đồng nghĩa với bạn.

Điều đó nói rằng, tính cụ thể hơn sẽ không ảnh hưởng đến ví dụ cụ thể này. "Quy trình" là một từ khá rộng. Chẳng hạn, nó có thực sự là "FooUpdateProcessor" (có thể trở thành "FooUpdater") không? Bạn không cần phải quá "sáng tạo" về cách đặt tên, nhưng nếu bạn đã viết mã, bạn có thể biết khá rõ những gì nó làm và không làm.

Cuối cùng, hãy nhớ rằng tên lớp trống không phải là tất cả những gì bạn và những người đọc mã của bạn phải tiếp tục - thường cũng có những không gian tên đang chơi. Những thứ đó thường có thể cung cấp cho người đọc đủ ngữ cảnh để thấy rõ lớp học của bạn nếu thực sự là gì, ngay cả khi tên trần của nó khá chung chung.

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.