Namizədlik dərsləri - bütün çağırışı qarşısını almaq üçün necə "Nə menecer"> menecer?

Uzun müddət əvvəl obyektlərin adlandırılması üçün məni "hüququ" izə qoyan bir məqaləni oxumuşdum (blog girişimi hesab edirəm): proqramınızdakı şeyi çağırmaqda çox diqqətli olun.

Məsələn, UserManager (normal bir iş tətbiqi kimi) istifadəçiləri, şirkətləri və ünvanlarını idarə edərsə, mən istifadəçi, şirkət və ünvanın sinfinə sahib UserManager və ehtimal UserManager , bir yerdə UserManager , UserManagerAddressManager bu işlərin UserManager görünür.

Belə ki, UserManager , UserManagerAddressManager nə etdiyini söyləyə bilərsiniz? Xeyr, çünki menecer, domen obyektləri ilə nə edə biləcəyiniz hər şey ilə gedən çox ümumi termindir.

Mən oxuduğum məqalədə çox xüsusi adları istifadə etmək məsləhət görülür. Bu bir C ++ proqramı və UserManager vəzifəsi təcrid və bir yığın pulsuz istifadə etmək üçün nəzərdə tutulmuşdur, istifadəçilər idarə deyil, onların doğum və ölüm qorumaq olardı. Hmmm, bəlkə onu UserShepherd .

Və ya, bəlkə, UserManager vəzifəsi hər bir istifadəçi obyektinin məlumatlarını yoxlamaq və məlumatları kriptoqrafik olaraq imzalamalıdır. Sonra bir UserRecordsClerk olacaq.

İndi bu fikir mənimlə sıxılmışdır, mən bunu tətbiq etməyə çalışıram. Və bu sadə fikir tapmaq şaşırtıcı çətindir.

Hansı dərslərin nə olduğunu və təsvir edə bilərəm (sürətli və çirkli kodlaşdırmağa qədər), mən yazdığım dərslər tam olaraq birdir . Bu təsvirdən adlara getmək üçün qaçırdığım adlar adların bir kataloqudur, anlayışları adlara təsvir edən bir lüğətdir.

Nəticədə şablon kataloqu kimi bir şeyləri yadda saxlamaq istərdim (tez-tez dizayn nümunələri asanlıqla zavod kimi obyekt adları verir)

  • Fabrika - digər obyektləri yaradır (dizayn desenindən alınan adlar)
  • Çoban - Çoban obyektlərin ömrünü, yaradılışını və bağlanmasını nəzarət edir
  • Sinxronizator - iki və ya daha çox obyekt arasında (və ya obyektlərin hiyerarxiyası) nüsxə məlumatları.
  • Dadı - obyektlərin yaradıldıqdan sonra "faydalı" vəziyyətə çatmasına kömək edir - məsələn, digər obyektlərə qoşulmaqla

  • və s

Bu problemlə necə məşğul olursunuz? Sabit bir söz varmı, sinifdə yeni adlar icad edirsənmi və ya adların çox vacib və ya yanlış olmadığını düşünürsən?

PS: Mən də bu məsələni müzakirə edən məqalələr və bloglarla əlaqə yaratmaqda maraqlıyam. Əvvəldən, burada məni düşünməyə təşviq edən orijinal məqalə: "Menecer" olmadan Java dərslərini adlandırmaq


Yeniləmə: Cavablar xülasəsi

Bu arada bu sualdan öyrəndiklərim haqqında qısa bir xülasə.

  • Yeni metafora (dadı) yaratmamağa çalışın
  • Digər çərçivələrə baxın

Bu mövzuda digər məqalələr / kitablar:

Və topladığım prefiks / soneklif adlarının cari siyahısı (subyektiv!) Cavablardan:

  • Koordinator
  • Builder
  • Yazıçı
  • Reader
  • Handler
  • Konteyner
  • Protokol
  • Məqsədi
  • Converter
  • nəzarətçi
  • Görünüş
  • Fabrika
  • Təşkilat
  • Kepçe

Və yol üçün yaxşı məsləhət:

İsminizin paralizi daxil etməyin. Bəli, adlar çox vacibdir, lakin çox vaxt sərf etmək üçün kifayət qədər vacib deyildir. 10 dəqiqə yaxşı bir adla çıxa bilməyəcəksinizsə, davam edin.

818
08 дек. set by froh42 08 dekabr . 2009-12-08 15:55 '09 da 15:55 'da 2009-12-08 15:55
@ 13 cavab

Bənzər bir sual soruşdum, amma mümkün olduğunda, artıq .NET Framework'təki adları kopyalamağa çalışıram və Java və Android-də fikirlər axtarıram.

Helper , ManagerUtil dövlətləri olmayan və bir qayda olaraq prosessual və statik olan əlaqələndirici dərslərə əlavə etdiyiniz qaçılmaz isimlərdir. Alternativ Coordinator .

Xüsusilə bənövşəyi adları ilə soruşun və Minder , Overseer , Supervisor , AdministratorMaster kimi şeylərə müraciət edin, amma dediyim kimi, onu istifadə etdiyiniz çərçivələrin adları kimi saxlamağı üstün tuturam.

.NET platformunda da tapa biləcəyiniz digər bəzi ümumi əlavələr (bu düzgün dövrdürsə):

  • Builder
  • Writer
  • Reader
  • Handler
  • Container
131
15 янв. 15 yanvarda Chris S tərəfindən verilmiş cavab 2010-01-15 16:31 '10 at 16:31 'da 2010-01-15 16:31

Source-codeodewordle.de səhifəsinə baxa bilərsiniz, mən .NET platformasının və digər bəzi kitabxanaların sinif adlarının ən çox istifadə olunan son cümlələrini təhlil etdim.

Top 20:

border=0
  • atributu
  • kimi
  • köməkçisi
  • toplama
  • Converter
  • işləyən
  • Məlumat
  • təchizatçı
  • bir istisna
  • xidmətləri
  • Element
  • menecer
  • node
  • variantları
  • zavod
  • Kontekst
  • element
  • dizaynçı
  • bazası
  • redaktoru
74
03 мая '12 в 0:44 2012-05-03 00:44 Markus Meyer tərəfindən 03 may 2012-ci ildə 0:44 da cavab verilib 2012-05-03 00:44

Bütün yaxşı adlarım var və tez-tez şeylər üçün ad seçərkən qayğıın əhəmiyyətini yazıram. Eyni səbəbdən, şeyləri çağırarkən metaforlardan qorxuram. Orijinal sualda "zavod" və "sinxronlaşdırıcı" nə demək istədiklərinə görə yaxşı adlar kimi görünür. Lakin, çoban və dayə deyil, çünki onlar metafora əsaslanır. Kodunuzdakı sinif tam mənada dadı ola bilməz; bir dadı deyirsiniz, çünki o, uşaqlar və ya uşaqlar üçün qayğıkeş olan bir valideynə çox bənzər bir şeylərə diqqət yetirir. Bu qeyri-rəsmi çıxışda normaldır, amma məncə (mənim fikrimcə), kodu bilmək istəyənlər tərəfindən dəstəklənilməli olan kodları təyin etmək üçün deyil.

Niyə? Metaforlar mədəniyyətdən asılıdır və tez-tez şəxsiyyətdən asılıdır. Sənin üçün "dadı" deyə çağırmaq çox aydın ola bilər, ancaq bəlkə də başqa birinə belə aydın deyil. Yalnız şəxsi istifadə üçün nəzərdə tutulan kodu yazmırsınızsa, bu barədə etibar edilməməlidir.

Hər halda, razılaşma metafora edə və ya poza bilər. "Fabrika" nın istifadəsi metafora əsaslanır, lakin çox uzun müddətdir və proqramlaşdırma dünyasında çox yaxşı tanınır, buna görə istifadə etmək təhlükəsizdir. Ancaq "dadı" və "çoban" qəbuledilməzdir.

40
08 дек. Cavab CesarGon 08 dekabr tərəfindən verilir . 2009-12-08 19:43 '09 da 19:43 'da 2009-12-08 19:43

Gerçək dünyaya doğru modelləşdirsək xxxFactory , xxxManager və ya xxxRepository olmadan biz bunu edə bilərik:

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

; -)

35
15 янв. cavab verildi herzmeister 15 yanvar. 2010-01-15 16:51 '10 at 4:51 2010-01-15 16:51

Thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages" və s. Haqqında yerləşdiriləcək şeylərə sürüşkən bir yamıq kimi səslənir.

Düşünürəm ki, bir monolitik Menecerin sinfi çox yaxşı bir dizayn deyil, "Menecer" in istifadəsi pis deyil. UserManager yerine UserAccountManager, UserProfileManager, UserSecurityManager və s. Bölüşdürə bilərik.

"Menecer" yaxşı bir sözdür, çünki bu, sinfi real şeyi əks etdirmir. " AccountsClerk "- istifadəçi məlumatlarını idarə edən bir sinifdir və ya işinin hesabının sekreteri olan birini təmsil edirmi?

28
Cavab cənabə verildi. 08 дек. Boy 08 dekabr 2009-12-08 16:26 '09 at 4:26 pm 2009-12-08 16:26

Bu sahədə məqalələrlə maraqlandığınız üçün, Stephen Egge "İsmilərin Krallığında İcra" adlı məqalədə maraqlı ola bilərsiniz:

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

19
15 янв. Yalan cavab verildi 2010-01-15 17:44 '10 at 17:44 2010-01-15 17:44

Manager və ya Helper bir sinifdə istifadə etməyi düşündüyümdə kodun qoxusu hesab edirəm, yəni mən hələ də doğru soyuducu olmadığımı və / və ya ortaq məsuliyyət prinsipini pozduğumu bildirirəm, buna görə refrakting və dizaynın daha çox diqqət çəkməsi tez-tez adlandırmanı asanlaşdırır.

Amma hətta yaxşı hazırlanmış dərslər həmişə özləri deyir və seçdiyiniz biznes modeli dərsləri və ya texniki infrastruktur dərsləri yaratdığınıza bağlıdır.

Biznes modellərinin sinifləri çətin ola bilər, çünki onlar hər bir domain üçün fərqlidirlər. Məsələn, bir domain (məsələn, LateRentalPolicy ) sahəsində siyasət dərsləri üçün bir çox şərtlər istifadə edirəm, lakin onlar adətən biznes istifadəçiləri, dizayn və adı dərsləri ilə paylaşa biləcəyiniz bir " hər yerdə mövcud dil " yaratmağa çalışırlar. real dünyadakı real fikirlər, obyektlər, hərəkətlər və hadisələr simulyasiya edir.

Texniki infrastruktur dərsləri bir az daha sadədir, çünki biz bildiyimiz domainləri təsvir edirlər. Dizayn şablonu adlarını InsertUserCommand, CustomerRepository, və ya SapAdapter. kimi sinif adlarına daxil etməyi üstün edirəm SapAdapter. . Mən niyyəti əvəzinə tətbiqin köçürülməsi ilə bağlı narahatlığı başa düşürəm, lakin dizayn nümunələri sinif dizaynının bu iki aspektindən kənara çıxır - heç olmasa, detalların gizlədilməsinə baxmayaraq, tətbiqin dizaynının şəffaf olmasını istədiyiniz infrastrukturla işləmək.

11
15 янв. Cavab Jeff Sternal tərəfindən verilir Yanvar 15 2010-01-15 17:22 '10 at 17:22 2010-01-15 17:22

GOF kitabının (deyildiyi) təyin etdiyi nümunələrlə otistik olmaq və sonra obyektlərin adları adlandırma siniflərində mənə uzun bir yol verir, onları təşkil edir və niyyətlərini bildirir. Çoxu bu nomenklaturu anlayacaq (ya da ən azından çoxu).

8
08 дек. Cavab Brian Agnew tərəfindən verilir 08 dekabr. 2009-12-08 15:59 '09 at 15:59 'da 2009-12-08 15:59

Mən XyzManager-dən daha çox sinif üçün daha konkret bir ad gətirə bilmərəmsə, bu, həqiqətən, sinifdə, yəni "kodun qoxusu" memarlıq birləşməsi olub-olmadığını yenidən nəzərdən keçirmək lazımdır.

6
03 мая '12 в 23:51 2012-05-03 23:51 cavab 03 May '12 'da 23:51' da Jasper van den Bosch tərəfindən verilmişdir 2012-05-03 23:51

Xüsusilə C # üçün, "Çərçivə Design Guide: Konvensiya, Deyimler və Şablonlar Yenidən istifadə edilə bilən. NET Kitabxanalar" adlı adlandırma mantığı haqqında çox yaxşı bir məlumat tapdıq.

Bu daha konkret sözləri axtarmaqla bağlı olaraq, tez-tez bir thesaurus istifadə və yaxşı söz tapmaq üçün müvafiq sözlər atlayın. Mən inkişaf SuchAndSuchManager daha yaxşı adlar SuchAndSuchManager bilirəm və ya bəzən belə anlayıram ki, həqiqətən bir neçə sinifə SuchAndSuchManager və sonra bu köhnəlmiş sinifin adı heç bir problem olmayacaqdır.

4
08 дек. cavab AaronLS 08 dec tərəfindən verilir . 2009-12-08 16:13 '09 at 16:13 2009-12-08 16:13

Yadda tutmaq üçün ən vacib şey kifayət qədər təsviri olan bir addır? Sınıq yerinə yetirməli olduğu adı baxaraq deyə bilərsinizmi? Sınıf adlarında "Menecer", "Xidmət" və ya "İşləyən" kimi sözləri istifadə etmək çox ümumi ola bilər, lakin bir çox proqramçılar onları istifadə etdikdən sonra, bu da sinfi üçün nə olduğunu anlamağa kömək edir.

Mən özüm bir çox fasad imicini istifadə etdim (ən azı, bu adlanır deyə düşünürəm). Yalnız bir istifadəçini təsvir edən Users sinifinə və "istifadəçi kolleksiyam" izləyən User sinifinə sahib ola bilərdim. UserManager bir UserManager çünki mən real həyatda menecerləri UserManager və onlara xatırlatmaq istəmirəm :) Çoxlu formu istifadə edərək mənim sinifin nə etdiyini başa düşməyə kömək edir.

3
08 дек. Cavab Droozle 08 dekabrda verilir . 2009-12-08 16:18 '09 at 16:18 'da 2009-12-08 16:18

Buradakı kritik şey kodunuzun görünürlüğünde uyğun olmalıdır, yəni. Kodunuza baxmağa / işləməyə ehtiyacı olan hər kəs adlandırma konvensiyasını başa düşsün, onda siz onları "CompanyThingamabob" və "UserDoohickey" adlandırmağa qərar verdiyiniz təqdirdə yaxşı olmalıdır. Bir şirkət üçün işləsəniz, ilk dayanma, adlandırma üçün təşkilatın razılığının olub olmadığını görməkdir. Əgər yoxsa və ya bir şirkətdə işləmirsinizsə, özünüz üçün əhəmiyyətli olan öz şərtlərinizi yaratın, ən azı səhvən kodunu kodlayan bir neçə etibarlı həmkarına / dostlara verin və məntiqli hər hansı bir rəy əlavə edin.

Bir başqa konvensiyanı qəbul etsəniz, hətta əgər qəbul olunarsa da, sizin səhifənizdən sıçramazsa, bu mənim kitabımda bir az səhvdir. İlk növbədə, mənim kodumu digər sənədlərə istinad etmədən anlamaq lazımdır, eyni zamanda, eyni sənayedə eyni sahədə başqa birinə anlaşılmaz deyil ki, kifayət qədər ümumi olmalıdır.

1
08 дек. Cavab Lazarus 08 dekabrda verilir. 2009-12-08 16:02 '09 at 16:02 'da 2009-12-08 16:02

Sisteminiz üçün istifadə etdiyiniz nümunələri nəzərdən keçirəcəyəm, bir qayda olaraq, adlandırma konvensiyaları / kataloqların təsnif edilməsi / qruplaşdırılması, istifadə edilən nümunə ilə müəyyən edilir. Mən şəxsən bu adlandırma konvensiyalarına riayət edirəm, çünki onlar başqa bir şəxs üçün kodumu almaq və onunla işləmək üçün ən yaxşı üsuldur.

UserRecordsClerk, UserRecordsClerk və CompanyRecordsClerk tərəfindən həyata keçirilən RecordsClerk ümumi interfeys uzantısına daha yaxşı izah edilə bilər və daha sonra ixtisaslaşmışdır, yəni alt siniflərin ümumiyyətlə nə olduğunu görmək üçün interfeysdəki metodlara baxa bilərsiniz.

Məsələn, məlumat üçün Design Patterns kitabına baxın, bu, böyük bir kitabdır və kodunuzla harada olacağınızı anlamanıza kömək edə bilər - əgər artıq istifadə etməsəniz !; o)

Şübhə etmirəm ki, əgər şablon yaxşı seçilib və lazım olduğu qədər istifadə olunarsa, kifayət qədər qeyri-intizamlı sadə sinif adları kifayətdir!

1
Cavab CJ tərəfindən verilir . 08 dekabr 2009-12-08 16:12 '09 at 16:12 'da 2009-12-08 16:12