Các lớp đặt tên - Làm thế nào để tránh gọi mọi thứ là Trình quản lý <WhatEver>? [đóng cửa]

Cách đây rất lâu, tôi đã đọc một bài viết (tôi tin rằng một mục blog) đưa tôi vào bài hát "đúng" về cách đặt tên các đối tượng: Hãy rất cẩn thận về việc đặt tên các thứ trong chương trình của bạn.

Ví dụ: nếu ứng dụng của tôi (như một ứng dụng kinh doanh thông thường) xử lý người dùng, công ty và địa chỉ tôi sẽ có một lớp User, một Companyvà một Addressmiền - và có lẽ ở đâu đó UserManager, một CompanyManagervà một AddressManagersẽ xuất hiện để xử lý những điều đó.

Vì vậy, bạn có thể nói những gì UserManager, CompanyManagervà AddressManagerlàm gì? Không, bởi vì Trình quản lý là một thuật ngữ rất chung chung phù hợp với mọi thứ bạn có thể làm với các đối tượng miền của mình.

Bài báo tôi đọc khuyến nghị sử dụng tên rất cụ thể. Nếu đó là một ứng dụng C ++ và UserManagercông việc của họ là phân bổ và giải phóng người dùng khỏi đống, thì nó sẽ không quản lý người dùng mà chỉ bảo vệ sinh tử của họ. Hmm, có lẽ chúng ta có thể gọi đây là a UserShepherd.

Hoặc có thể UserManagercông việc của họ là kiểm tra dữ liệu của từng đối tượng Người dùng và ký dữ liệu bằng mật mã. Sau đó, chúng tôi sẽ có một UserRecordsClerk.

Bây giờ ý tưởng này bị mắc kẹt với tôi, tôi cố gắng áp dụng nó. Và tìm thấy ý tưởng đơn giản này khó khăn đáng kinh ngạc.

Tôi có thể mô tả những gì các lớp làm và (miễn là tôi không rơi vào mã hóa nhanh & bẩn) các lớp tôi viết thực hiện chính xác một điều. Những gì tôi bỏ lỡ để đi từ mô tả đó đến các tên là một loại danh mục tên, một từ vựng ánh xạ các khái niệm thành tên.

Cuối cùng tôi muốn có một cái gì đó giống như một danh mục mẫu trong tâm trí của tôi (các mẫu thiết kế thường xuyên dễ dàng cung cấp các tên đối tượng, ví dụ như một nhà máy )

• Factory - Tạo các đối tượng khác (đặt tên được lấy từ mẫu thiết kế)
• Người chăn cừu - Người chăn cừu xử lý thời gian sống của các vật thể, sự sáng tạo và tắt máy của chúng
• Đồng bộ hóa - Sao chép dữ liệu giữa hai hoặc nhiều đối tượng (hoặc phân cấp đối tượng)

• Vú em - Giúp các đối tượng đạt đến trạng thái "có thể sử dụng" sau khi tạo - ví dụ: bằng cách nối dây với các đối tượng khác

• Vân vân.

Vì vậy, làm thế nào để bạn xử lý vấn đề đó? Bạn có một từ vựng cố định, bạn có phát minh ra tên mới một cách nhanh chóng hay bạn xem xét việc đặt tên những thứ không quá quan trọng hoặc sai?

Tái bút: Tôi cũng quan tâm đến các liên kết đến các bài báo và blog thảo luận về vấn đề này. Để bắt đầu, đây là bài viết gốc khiến tôi suy nghĩ về nó: Đặt tên các lớp Java mà không có 'Trình quản lý'

Cập nhật: Tóm tắt câu trả lời

Trong thời gian này, đây là một bản tóm tắt về những gì tôi học được từ câu hỏi này.

• Cố gắng không tạo ra ẩn dụ mới (Vú em)
• Hãy nhìn vào những khuôn khổ khác làm gì

Các bài viết / sách về chủ đề này:

• Những tên nào bạn thấy mình đang chuẩn bị / thêm vào các lớp học thường xuyên?
• Cách tiếp cận tốt nhất để đặt tên lớp là gì?
• Sách: Các mẫu thiết kế: Các yếu tố của phần mềm hướng đối tượng có thể tái sử dụng (Bìa cứng)
• Sách: Các mô hình kiến ​​trúc ứng dụng doanh nghiệp (Bìa cứng)
• Sách: Mẫu thực hiện (Bìa mềm)

Và một danh sách hiện tại của tiền tố tên / hậu tố tôi đã thu thập (chủ quan!) Từ các câu trả lời:

• Điều phối viên
• Người xây dựng
• nhà văn
• Người đọc
• Xử lý
• Thùng đựng hàng
• Giao thức
• Mục tiêu
• Bộ chuyển đổi
• Bộ điều khiển
• Lượt xem
• Nhà máy
• Thực thể
• Gầu múc

Và một mẹo hay cho con đường:

Đừng để bị tê liệt khi đặt tên. Đúng, tên rất quan trọng nhưng chúng không đủ quan trọng để lãng phí thời gian khổng lồ. 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.

Tôi đã hỏi một câu hỏi tương tự , nhưng ở đâu có thể, tôi cố gắng sao chép các tên đã có trong khung công tác .NET và tôi tìm ý tưởng trong các khung công tác Java và Android .

Dường như Helper, Managervà Utillà những danh từ không thể tránh khỏi mà bạn đính kèm để phối hợp các lớp không chứa trạng thái và nói chung là thủ tục và tĩnh. Một thay thế là Coordinator.

Bạn có thể nhận prosey đặc biệt là màu tím với những cái tên và đi cho những thứ như Minder, Overseer, Supervisor, Administrator, và Master, nhưng như tôi đã nói tôi muốn giữ nó như tên khuôn khổ bạn đang sử dụng để.

Một số hậu tố phổ biến khác (nếu đó là thuật ngữ chính xác) bạn cũng tìm thấy trong .NET framework là:

• Builder
• Writer
• Reader
• Handler
• Container

Bạn có thể xem qua source-code-wordle.de , tôi đã phân tích ở đó các hậu tố được sử dụng thường xuyên nhất của các tên lớp của .NET framework và một số thư viện khác.

Top 20 là:

• thuộc tính
• kiểu
• người giúp đỡ
• bộ sưu tập
• chuyển đổi
• xử lý
• thông tin
• các nhà cung cấp
• ngoại lệ
• dịch vụ
• thành phần
• giám đốc
• nút
• Lựa chọn
• nhà máy
• bối cảnh
• mục
• nhà thiết kế
• căn cứ
• biên tập viên

Tôi là tất cả những cái tên hay và tôi thường viết về tầm quan trọng của việc cẩn thận khi chọn tên cho mọi thứ. Vì lý do rất giống nhau này, tôi cảnh giác với những ẩn dụ khi đặt tên cho mọi thứ. Trong câu hỏi ban đầu, "nhà máy" và "bộ đồng bộ hóa" trông giống như những cái tên hay cho ý nghĩa của chúng. Tuy nhiên, "người chăn" và "bảo mẫu" thì không, bởi vì chúng dựa trên phép ẩn dụ . Một lớp trong mã của bạn không thể là một người giữ trẻ theo nghĩa đen ; bạn gọi nó là bảo mẫu vì nó chăm sóc một số thứ khác rất giống một bảo mẫu ngoài đời thực chăm sóc trẻ sơ sinh hoặc trẻ nhỏ. Điều đó ổn trong lời nói không chính thức, nhưng không ổn (theo ý kiến ​​của tôi) đối với việc đặt tên các lớp trong mã sẽ phải được duy trì bởi ai biết ai biết khi nào.

Tại sao? Bởi vì ẩn dụ phụ thuộc vào văn hóa và thường phụ thuộc vào từng cá nhân. Đối với bạn, việc đặt tên cho một "bảo mẫu" có thể rất rõ ràng, nhưng có lẽ nó không rõ ràng với người khác. Chúng ta không nên dựa vào điều đó, trừ khi bạn viết mã chỉ dành cho sử dụng cá nhân.

Trong mọi trường hợp, quy ước có thể tạo ra hoặc phá vỡ một phép ẩn dụ. Việc sử dụng "nhà máy" tự nó dựa trên một phép ẩn dụ, nhưng nó đã xuất hiện khá lâu và hiện khá nổi tiếng trong thế giới lập trình, vì vậy tôi sẽ nói rằng nó an toàn khi sử dụng. Tuy nhiên, "bảo mẫu" và "người chăn" là không thể chấp nhận được.

Chúng ta có thể làm mà không cần bất kỳ xxxFactory, xxxManagerhoặc xxxRepositorycác lớp nếu chúng ta mô hình hóa thế giới thực một cách chính xác:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)

Nghe có vẻ như một con dốc trơn trượt đến một cái gì đó sẽ được đăng trên thed Dailywtf.com, "ManagerOfP PeopleWhoHaveMortgages", v.v.

Tôi cho rằng đúng là một lớp Trình quản lý nguyên khối không phải là thiết kế tốt, nhưng sử dụng 'Trình quản lý' không phải là xấu. Thay vì UserManager, chúng tôi có thể chia nó thành UserAccountManager, UserProfileManager, UserSecurityManager, v.v.

'Người quản lý' là một từ tốt vì nó cho thấy rõ ràng một lớp không đại diện cho một 'thế giới thực'. 'AccountClerk' - tôi phải nói như thế nào nếu đó là một lớp quản lý dữ liệu người dùng hoặc đại diện cho ai đó là Thư ký tài khoản cho công việc của họ?

Vì bạn quan tâm đến các bài viết trong lĩnh vực này, bạn có thể quan tâm đến bài viết ý kiến ​​của Steve Yegge "Thi hành tại Vương quốc Danh từ":

http://steve-yegge.blogspot.com/2006/03/execut-in-kingdom-of-nouns.html

Khi tôi nghĩ về việc sử dụng Managerhoặc Helpertrong một tên lớp, tôi coi đó là mùi mã có nghĩa là tôi chưa tìm thấy sự trừu tượng đúng và / hoặc tôi vi phạm nguyên tắc trách nhiệm duy nhất , do đó, tái cấu trúc và nỗ lực nhiều hơn vào thiết kế thường làm cho việc đặt tên dễ dàng hơn nhiều.

Nhưng ngay cả các lớp được thiết kế tốt cũng không (luôn luôn) tự đặt tên cho mình và các lựa chọn của bạn một phần phụ thuộc vào việc bạn đang tạo các lớp mô hình kinh doanh hay các lớp cơ sở hạ tầng kỹ thuật.

Các lớp mô hình kinh doanh có thể khó, bởi vì chúng khác nhau cho mọi miền. Có một số thuật ngữ tôi sử dụng rất nhiều, như Policyđối với các lớp chiến lược trong một miền (ví dụ LateRentalPolicy:), nhưng chúng thường bắt nguồn từ việc cố gắng tạo ra một " ngôn ngữ phổ biến " mà bạn có thể chia sẻ với người dùng doanh nghiệp, thiết kế và đặt tên lớp để chúng mô hình thực thế giới ý tưởng, đối tượng, hành động và sự kiện.

Các lớp cơ sở hạ tầng kỹ thuật dễ dàng hơn một chút, vì chúng mô tả các miền mà chúng ta biết thực sự rõ. Tôi thích kết hợp các tên mẫu thiết kế vào các tên lớp, như InsertUserCommand, CustomerRepository,hoặc SapAdapter.tôi hiểu mối quan tâm về việc truyền đạt triển khai thay vì mục đích, nhưng các mẫu thiết kế kết hợp hai khía cạnh này của thiết kế lớp - ít nhất là khi bạn đang xử lý cơ sở hạ tầng, nơi bạn muốn thiết kế triển khai phải minh bạch ngay cả khi bạn đang ẩn các chi tiết.

Được biết đến với các mẫu như được định nghĩa bởi (giả sử) cuốn sách GOF và đặt tên các đối tượng theo sau chúng giúp tôi có một chặng đường dài trong việc đặt tên các lớp, sắp xếp chúng và truyền đạt ý định. Hầu hết mọi người sẽ hiểu danh pháp này (hoặc ít nhất là một phần chính của nó).

Nếu tôi không thể đưa ra một tên cụ thể hơn cho lớp của mình hơn XyzManager thì đây sẽ là một điểm để tôi xem xét lại liệu đây có thực sự là chức năng thuộc về một lớp hay không, tức là một mùi 'mã' kiến ​​trúc.

Tôi nghĩ điều quan trọng nhất cần ghi nhớ là: tên có đủ mô tả không? Bạn có thể nói bằng cách nhìn vào cái tên mà Class phải làm không? Sử dụng các từ như "Manager", "Service" hoặc "Handler" trong tên lớp của bạn có thể được coi là quá chung chung, nhưng vì rất nhiều lập trình viên sử dụng chúng, nó cũng giúp hiểu được lớp học dùng để làm gì.

Bản thân tôi đã sử dụng mô hình mặt tiền rất nhiều (ít nhất, tôi nghĩ đó là tên gọi của nó). Tôi có thể có một Userlớp mô tả chỉ một người dùng và một Userslớp theo dõi "bộ sưu tập người dùng" của tôi. Tôi không gọi lớp là UserManagervì tôi không thích người quản lý ngoài đời thực và tôi không muốn được nhắc nhở về họ :) Đơn giản chỉ cần sử dụng dạng số nhiều giúp tôi hiểu được lớp học làm gì.

Cụ thể với C #, tôi đã tìm thấy "Nguyên tắc thiết kế khung: Quy ước, thành ngữ và mẫu cho thư viện .NET có thể tái sử dụng" để có nhiều thông tin tốt về logic đặt tên.

Theo như tìm kiếm những từ cụ thể hơn, tôi thường sử dụng từ điển đồng nghĩa và nhảy qua các từ liên quan để thử và tìm một từ tốt. Mặc dù vậy, tôi cố gắng không dành nhiều thời gian cho nó, khi tôi phát triển thông qua việc phát triển những cái tên hay hơn, hoặc đôi khi nhận ra rằng SuchAndSuchManagerthực sự nên chia thành nhiều lớp, và sau đó tên của lớp bị phản đối đó trở thành một vấn đề .

Tôi tin rằng điều quan trọng ở đây là phải nhất quán trong phạm vi khả năng hiển thị mã của bạn, tức là miễn là mọi người cần xem / làm việc trên mã của bạn hiểu quy ước đặt tên của bạn thì điều đó sẽ ổn, ngay cả khi bạn quyết định gọi cho họ 'CompanyT Breathamabob' và 'UserDoohickey'. Điểm dừng đầu tiên, nếu bạn làm việc cho một công ty, là để xem liệu có một quy ước công ty để đặt tên. Nếu không có hoặc bạn không làm việc cho một công ty thì hãy tạo ra các thuật ngữ của riêng bạn cho bạn, hãy chuyển nó xung quanh một vài đồng nghiệp / bạn bè đáng tin cậy, ít nhất là mã tình cờ, và kết hợp bất kỳ phản hồi nào có ý nghĩa.

Áp dụng quy ước của người khác, ngay cả khi nó được chấp nhận rộng rãi, nếu nó không nhảy ra khỏi trang của bạn là một chút sai lầm trong cuốn sách của tôi. Trước hết tôi cần hiểu mã của mình mà không cần tham khảo tài liệu khác nhưng đồng thời nó cũng phải chung chung đến mức không thể hiểu được với người khác trong cùng lĩnh vực.

Tôi sẽ xem xét các mẫu bạn đang sử dụng cho hệ thống của mình, các quy ước đặt tên / phân loại / nhóm các lớp có xu hướng được xác định bởi mẫu được sử dụng. Cá nhân, tôi tuân theo các quy ước đặt tên này vì chúng là cách khả dĩ nhất để người khác có thể nhận mã của tôi và chạy với nó.

Ví dụ, UserRecordsClerk có thể được giải thích tốt hơn khi mở rộng giao diện RecordsClerk chung mà cả UserRecordsClerk và CompanyRecordsClerk đều thực hiện và sau đó chuyên môn hóa, có nghĩa là người ta có thể nhìn vào các phương thức trong giao diện để xem các lớp con của nó thường làm gì.

Xem một cuốn sách như Mẫu thiết kế để biết thông tin, đây là một cuốn sách tuyệt vời và có thể giúp bạn làm rõ nơi bạn đang nhắm đến với mã của mình - nếu bạn chưa sử dụng nó! ; o)

Tôi nghĩ rằng miễn là mô hình của bạn được lựa chọn và sử dụng càng xa càng phù hợp, thì những tên lớp đơn giản khá khó hiểu sẽ đủ!