Як називати класи - Як уникнути називання всього "<WhatEver> Manager"? [зачинено]

Давно я прочитав статтю (я вважаю, що це запис у блозі), яка поставила мене на "правильний" шлях до іменування об'єктів: будьте дуже скрупульозні щодо називання речей у вашій програмі.

Наприклад , якщо моя заявка була (як типовий бізнес - додаток) обробки користувачів, компанії і адреси я є User, Companyі в Addressклас домену - і , ймовірно , де - то UserManager, CompanyManagerі AddressManagerбуде спливав , який обробляє ці речі.

Тож чи можете ви сказати, що це робити UserManager, CompanyManagerі AddressManagerробити? Ні, тому що "Менеджер" - це дуже загальний термін, який відповідає всім, що ви можете зробити з об'єктами вашого домену.

У статті, яку я прочитав, рекомендується використовувати дуже конкретні назви. Якщо це була програма C ++, а UserManagerзавданням було виділення та звільнення користувачів із купи, вона не керувала б користувачами, а захищала їх народження та смерть. Хм, можливо, ми могли б це назвати UserShepherd.

Або, можливо UserManager, завдання полягає в тому, щоб перевірити дані кожного об'єкта користувача і підписати дані криптографічно. Тоді ми мали б UserRecordsClerk.

Тепер, коли ця ідея застрягла у мене, я намагаюся її застосувати. І знайти цю просту ідею напрочуд важко.

Я можу описати, що роблять класи, і (доки я не ковзаю швидке та брудне кодування) класи, які я пишу, роблять точно одне . Що я сумую, щоб перейти від цього опису до імен, це своєрідний каталог імен, словник, який відображає поняття на імена.

Зрештою, я хотів би мати на увазі щось на зразок каталогу візерунків (часто шаблони дизайну легко надають назви об'єктів, наприклад, фабрика )

• Фабрика - створює інші об'єкти (називання, взяті за схемою дизайну)
• Вівчарка - вівчарка обробляє термін експлуатації об’єктів, їх створення та відключення
• Синхронізатор - копіює дані між двома або більше об'єктами (або ієрархіями об'єктів)

• Няня - допомагає об'єктам досягти "зручного" стану після створення - наприклад, шляхом підключення до інших об'єктів

• тощо.

Отже, як ви вирішуєте це питання? Чи є у вас фіксований словник, ви вигадуєте нові імена на льоту або вважаєте, що називати речі не дуже важливими чи неправильними?

PS: Мене також цікавлять посилання на статті та блоги, які обговорюють цю проблему. Для початку ось оригінальна стаття, яка змусила мене замислитися над цим: називання Java-класів без "менеджера"

Оновлення: підсумок відповідей

Ось невеличкий підсумок того, що я дізнався з цього питання тим часом.

• Намагайтеся не створювати нових метафор (Няня)
• Погляньте, що роблять інші рамки

Інші статті / книги на цю тему:

• Які імена ви вважаєте, що регулярно готуєтесь / відвідуєте заняття?
• Який найкращий підхід до іменування класів?
• Книга: Шаблони дизайну: Елементи багаторазового об’єктно-орієнтованого програмного забезпечення (тверда обкладинка)
• Книга: Шаблони архітектури прикладних програм підприємства (тверда обкладинка)
• Книга: Шаблони впровадження (М'яка обкладинка)

І поточний список іменних префіксів / суфіксів, які я зібрав (суб'єктивно!) З відповідей:

• Координатор
• Будівельник
• Письменник
• Читач
• Обробник
• Контейнер
• Протокол
• Ціль
• Перетворювач
• Контролер
• Вид
• Заводська
• Суб'єкт
• Відро

І хороша порада для дороги:

Не слід називати параліч. Так, імена дуже важливі, але вони недостатньо важливі для того, щоб витрачати величезну кількість часу. Якщо ви не можете придумати гарне ім’я за 10 хвилин, рухайтеся далі.

Я задав подібне запитання , але там, де це можливо, я намагаюся скопіювати імена, які вже є в рамках .NET , і шукаю ідеї в рамках Java та Android .

Здається Helper, Managerі Utilє неминучими іменниками, які ви додаєте для координаційних класів, які не містять стану і, як правило, є процедурними та статичними. Альтернативою є Coordinator.

Ви можете отримати особливо фіолетовий prosey з іменами і йти на такі речі , як Minder, Overseer, Supervisor, Administratorі Master, але , як я сказав , що я вважаю за краще тримати його , як ви звикли до рамкових імен.

Деякі інші поширені суфікси (якщо це правильний термін), які ви також знаходите в .NET- рамках:

• Builder
• Writer
• Reader
• Handler
• Container

Ви можете поглянути на source-code-wordle.de , я проаналізував там найбільш часто використовувані суфікси назв класів .NET Framework та деяких інших бібліотек.

Топ-20 - це:

• атрибут
• тип
• помічник
• колекція
• перетворювач
• обробник
• інформація
• постачальник
• виняток
• сервіс
• елемент
• менеджер
• вузол
• варіант
• фабрика
• контекст
• пункт
• дизайнер
• база
• редактор

Я все за хороші імена, і часто пишу про важливість бути дуже обережним при виборі імен для речей. З цієї самої причини я насторожено ставлюсь до метафор, коли називаю речі. У первісному питанні "фабрика" та "синхронізатор" виглядають як хороші імена за тим, що вони, здається, означають. Однак "пастух" і "няня" не є, тому що вони засновані на метафорах . Клас у вашому коді не може бути буквально нянею; Ви називаєте це нянею, тому що вона дуже доглядає за іншими речами, як няня, яка реально доглядає за дітьми чи дітьми. Це добре в неформальній промові, але не в порядку (на мій погляд) для іменування класів у коді, який повинен підтримувати хто знає, хто знає, коли.

Чому? Тому що метафори залежать від культури і часто залежать від особистості. Для вас називання класу «нянькою» може бути дуже зрозумілим, але, можливо, це не так зрозуміло комусь іншому. Ми не повинні покладатися на це, якщо тільки ви не пишете код, призначений лише для особистого використання.

У будь-якому випадку, умовність може внести або порушити метафору. Використання "фабрики" засноване на метафорі, але такої, яка існує вже досить давно і в даний час досить відома в світі програмування, тому я б сказав, що це безпечно у використанні. Однак "няня" та "пастух" неприйнятні.

Ми могли б обійтися без якого - або xxxFactory, xxxManagerабо xxxRepositoryкласів , якщо ми змоделювали реальний світ правильно:

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

;-)

Це звучить як слизький нахил до того, що буде розміщено на thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages" тощо.

Я гадаю, що це правильно, що один монолітний клас Manager - це не гарний дизайн, але використання "Менеджера" - це не погано. Замість UserManager ми можемо розбити його на UserAccountManager, UserProfileManager, UserSecurityManager тощо.

"Менеджер" - це гарне слово, оскільки це чітко показує, що клас не представляє "речі" реального світу. "AccountsClerk" - як я повинен сказати, чи це клас, який керує даними користувачів, або представляє когось, хто є службовцем облікових записів для своєї роботи?

Оскільки вас цікавлять статті в цій галузі, вас може зацікавити стаття на думку Стіва Йегге "Страта в Королівстві іменників":

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

Коли я думаю про використання Managerабо Helperв назві класу, я вважаю це кодовим запахом, що означає, що я ще не знайшов правильної абстракції та / або порушую принцип єдиної відповідальності , тому рефакторинг і більше зусиль прикладаю до дизайну часто робить імена набагато простішими.

Але навіть добре спроектовані класи не називають себе (завжди), і ваш вибір частково залежить від того, створюєте ви класи бізнес-моделей або класи технічної інфраструктури.

Класи бізнес-моделей можуть бути важкими, оскільки вони різні для кожної галузі. Є деякі терміни, які я дуже використовую, як, наприклад, Policyдля стратегічних класів у домені (наприклад, LateRentalPolicy), але вони зазвичай випливають із спроби створити " всюдисущу мову ", якою ви можете поділитися з діловими користувачами, розробляючи та називаючи класи, щоб вони моделювали реальні -світові ідеї, предмети, дії та події.

Класи технічної інфраструктури трохи простіші, оскільки вони описують домени, які ми справді добре знаємо. Я вважаю за краще включати імена шаблонів дизайну в назви класів, як-от InsertUserCommand, CustomerRepository,або SapAdapter.я розумію занепокоєння щодо спілкування про реалізацію замість намірів, але шаблони дизайну укладають шлюб із цими двома аспектами дизайну класів - принаймні, коли ви маєте справу з інфраструктурою, де вам потрібно реалізація дизайн , щоб бути прозорою , навіть коли ви приховуєте деталі.

Будучи справжнім з візерунками, визначеними (скажімо), книгою GOF , і називанням об'єктів після них дає мені довгий шлях у називанні класів, організації їх та спілкуванні намірів. Більшість людей зрозуміють цю номенклатуру (або хоча б більшу частину її).

Якщо я не можу придумати конкретнішу назву для свого класу, ніж XyzManager, це було б для мене моментом переглянути, чи справді це функціональність, яка належить разом до класу, тобто архітектурний «запах коду».

Я думаю, що найважливіше, що слід пам’ятати, це: чи достатньо описового ім’я? Чи можете ви сказати, поглянувши на ім’я, що повинен робити клас? Використання таких слів, як "Менеджер", "Сервіс" або "Обробник" у назвах вашого класу, можна вважати занадто загальним, але оскільки багато програмістів використовують їх, це також допомагає зрозуміти, для чого клас.

Я сам багато використовував фасадний малюнок (принаймні, я думаю, що це так називається). Я міг би мати Userклас, який описує лише одного користувача, і Usersклас, який відслідковує мою "колекцію користувачів". Я не називаю клас а, UserManagerтому що мені не подобаються менеджери в реальному житті і я не хочу, щоб про них нагадували :) Просто використання форми множини допомагає мені зрозуміти, що робить клас.

Характерно для C #, я виявив "Правила дизайну рамок: Конвенції, ідіоми та зразки для багаторазових бібліотек .NET" містять багато корисної інформації про логіку називання.

Щодо пошуку цих більш конкретних слів, я часто використовую тезаурус і перескакую відповідні слова, щоб спробувати знайти хороше. Я намагаюся не витрачати на це багато часу, хоча, просуваючись вдосконалення, я придумую кращі імена, або іноді розумію, що SuchAndSuchManagerнасправді слід розбити на декілька класів, і тоді ім'я цього застарілого класу стає непроблемним .

Я вважаю, що найважливішим тут є бути послідовним у сфері видимості вашого коду, тобто до тих пір, поки всі, кому потрібно дивитись / працювати над вашим кодом, розуміють вашу умову іменування, то це повинно бути добре, навіть якщо ви вирішите зателефонувати їм. 'CompanyThingamabob' та 'UserDoohickey'. Перша зупинка, якщо ви працюєте в компанії, - це перевірити, чи існує компанія, яка передбачає назву. Якщо в компанії немає або ви не працюєте, то створіть свої власні, використовуючи терміни, які мають для вас сенс, обведіть їх кількома довіреними колегами / друзями, які хоча б випадково кодують, і включіть будь-які відгуки, що мають сенс.

Застосування чужої конвенції, навіть коли вона широко прийнята, якщо вона не відскакує від сторінки у вас, є моєю помилкою в моїй книзі. Перш за все, я повинен розуміти свій код без посилання на іншу документацію, але в той же час він повинен бути достатньо загальним, щоб це було незрозумілим для когось іншого в тій же галузі в тій же галузі.

Я б врахував шаблони, які ви використовуєте для вашої системи, конвенції про іменування / каталогізацію / групування класів тенденцій визначають за використовуваним шаблоном. Особисто я дотримуюсь цих умов іменування, оскільки вони є найбільш ймовірним способом, щоб інша людина змогла забрати мій код і запустити його.

Наприклад, UserRecordsClerk може бути краще пояснено як розширення загального інтерфейсу RecordsClerk, який реалізують і UserRecordsClerk, і CompanyRecordsClerk, а потім спеціалізуються на них, що означає, що можна подивитися на методи в інтерфейсі, щоб побачити, для чого взагалі є його підкласи.

Інформацію див. У такій книзі, як " Шаблони дизайну" , це відмінна книга і може допомогти вам зрозуміти, куди ви прагнете бути зі своїм кодом - якщо ви вже не використовуєте його! ; o)

Я вважаю, що ваш шаблон обраний і використаний, наскільки це доречно, тоді досить досить неінвентивної прямої назви класів!