Pertanyaan Kelas Penamaan - Bagaimana cara menghindari memanggil semua “ Manager”? [Tutup]


Beberapa waktu yang lalu saya telah membaca sebuah artikel (saya percaya sebuah entri blog) yang menempatkan saya pada jalur yang "benar" pada penamaan objek: Sangatlah sangat teliti tentang menamai hal-hal dalam program Anda.

Misalnya jika aplikasi saya adalah (sebagai aplikasi bisnis biasa) yang menangani pengguna, perusahaan, dan alamat yang saya miliki User, Sebuah Company dan sebuah Address kelas domain - dan mungkin di suatu tempat UserManager, Sebuah CompanyManager dan sebuah AddressManager akan muncul yang menangani hal-hal itu.

Jadi bisakah Anda memberi tahu apa itu UserManager, CompanyManager dan AddressManager melakukan? Tidak, karena Manajer adalah istilah yang sangat sangat umum yang cocok untuk apa pun yang dapat Anda lakukan dengan objek domain Anda.

Artikel yang saya baca menyarankan untuk menggunakan nama yang sangat spesifik. Jika itu aplikasi C ++ dan UserManagerPekerjaan adalah mengalokasikan dan membebaskan pengguna dari tumpukan itu tidak akan mengelola pengguna tetapi menjaga kelahiran dan kematian mereka. Hmm, mungkin kita bisa menyebutnya a UserShepherd.

Atau mungkin itu UserManagerTugasnya adalah memeriksa setiap data objek Pengguna dan menandatangani data secara kriptografis. Maka kita akan memiliki UserRecordsClerk.

Sekarang ide ini melekat pada saya, saya mencoba untuk menerapkannya. Dan temukan ide sederhana ini luar biasa keras.

Saya dapat menggambarkan apa yang kelas lakukan dan (selama saya tidak masuk ke dalam pengkodean cepat & kotor) kelas yang saya tulis benar-benar dilakukan satu benda. Apa yang saya rindukan dari deskripsi itu ke nama adalah semacam katalog nama, kosakata yang memetakan konsep ke nama.

Pada akhirnya saya ingin memiliki sesuatu seperti katalog pola dalam pikiran saya (seringkali pola desain dengan mudah memberikan nama-nama objek, misalnya a pabrik)

  • Pabrik - Menciptakan objek lain (penamaan yang diambil dari pola desain)
  • Shepherd - Seorang gembala menangani seumur hidup objek, kreasi mereka, dan shutdown
  • Synchronizer - Menyalin data antara dua atau lebih objek (atau hierarki objek)
  • Nanny - Membantu objek mencapai keadaan "dapat digunakan" setelah pembuatan - misalnya dengan memasang kabel ke objek lain

  • dll dll

Jadi, bagaimana Anda menangani masalah itu? Apakah Anda memiliki kosakata yang tetap, apakah Anda menemukan nama-nama baru dengan cepat atau apakah Anda menganggap menamai hal-hal yang tidak begitu penting atau salah?

P.S .: Saya juga tertarik dengan tautan ke artikel dan blog yang membahas masalah ini. Sebagai permulaan, inilah artikel asli yang membuat saya berpikir tentang hal ini: Menamai Kelas Java tanpa 'Manajer'


Pembaruan: Ringkasan jawaban

Berikut ini sedikit ringkasan dari apa yang saya pelajari dari pertanyaan ini untuk sementara.

  • Cobalah untuk tidak membuat metafora baru (Nanny)
  • Lihatlah apa yang dilakukan oleh kerangka lain

Artikel / buku lebih lanjut tentang topik ini:

Dan daftar nama awalan / akhiran nama yang saya kumpulkan (secara subyektif!) Dari jawabannya:

  • Koordinator
  • Pembangun
  • Penulis
  • Pembaca
  • Handler
  • Wadah
  • Protokol
  • Target
  • Konverter
  • Kontroler
  • Melihat
  • Pabrik
  • Kesatuan
  • Ember

Dan tip yang bagus untuk jalan:

Jangan lumpuhkan penamaan. Ya, nama sangat penting tetapi mereka tidak cukup penting untuk menghabiskan banyak waktu. Jika Anda tidak bisa memikirkan nama baik dalam 10 menit, lanjutkan.


934
2017-12-08 13:26


asal


Jawaban:


Saya bertanya a pertanyaan serupa, tetapi jika mungkin saya mencoba untuk menyalin nama-nama yang sudah ada dalam kerangka .NET, dan saya mencari ide-ide dalam kerangka Java dan Android.

Kelihatannya Helper, Manager, dan Util adalah kata benda yang tidak dapat dihindari yang Anda pasang untuk mengkoordinasikan kelas-kelas yang tidak mengandung negara bagian dan umumnya bersifat prosedural dan statis. Alternatifnya adalah Coordinator.

Anda bisa mendapatkan prosa ungu dengan nama dan pergi untuk hal-hal seperti Minder, Overseer, Supervisor, Administrator, dan Master, tetapi seperti yang saya katakan, saya lebih suka menyimpannya seperti nama-nama kerangka yang Anda gunakan.

Beberapa sufiks umum lainnya (jika itu adalah istilah yang benar) yang Anda temukan dalam kerangka .NET adalah:

  • Builder
  • Writer
  • Reader
  • Handler
  • Container

153
2017-12-08 12:59



Anda bisa melihatnya source-code-wordle.deSaya telah menganalisis sufiks yang paling sering digunakan dari nama kelas dari kerangka .NET dan beberapa pustaka lainnya.

20 teratas adalah:

  • atribut
  • mengetik
  • pembantu
  • koleksi
  • konverter
  • pawang
  • info
  • pemberi
  • pengecualian
  • layanan
  • elemen
  • manajer
  • simpul
  • pilihan
  • pabrik
  • konteks
  • barang
  • perancang
  • mendasarkan
  • editor

88
2017-12-08 13:13



Saya semua untuk nama baik, dan saya sering menulis tentang pentingnya berhati-hati ketika memilih nama untuk berbagai hal. Untuk alasan yang sama ini, saya mewaspadai metafora ketika menyebutkan sesuatu. Dalam pertanyaan awal, "pabrik" dan "penyelaras" tampak seperti nama yang bagus untuk apa yang mereka maksud. Namun, "shepherd" dan "nanny" tidak, karena mereka didasarkan pada metafora. Kelas di kode Anda tidak bisa secara harfiah seorang pengasuh; Anda menyebutnya pengasuh karena terlihat setelah beberapa hal lain sangat mirip pengasuh kehidupan nyata terlihat setelah bayi atau anak-anak. Itu tidak apa-apa dalam pembicaraan informal, tapi tidak OK (menurut saya) untuk penamaan kelas dalam kode yang harus dipelihara oleh siapa yang tahu siapa yang tahu kapan.

Mengapa? Karena metafora adalah budaya tergantung dan sering juga tergantung pada individu. Bagi Anda, menyebut kelas "pengasuh" bisa sangat jelas, tetapi mungkin tidak jelas bagi orang lain. Kita seharusnya tidak bergantung pada itu, kecuali Anda menulis kode yang hanya untuk penggunaan pribadi.

Bagaimanapun, konvensi dapat membuat atau menghancurkan metafora. Penggunaan "pabrik" sendiri didasarkan pada metafora, tetapi yang sudah ada cukup lama dan saat ini cukup terkenal di dunia pemrograman, jadi saya akan mengatakan itu aman untuk digunakan. Namun, "nanny" dan "shepherd" tidak bisa diterima.


50
2017-12-08 13:18



Kita bisa melakukannya tanpa apapun xxxFactory, xxxManager atau xxxRepository kelas jika kita membuat model dunia nyata dengan benar:

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

;-)


39
2017-12-08 13:02



Kedengarannya seperti kemiringan licin untuk sesuatu yang akan diposting di thedailywtf.com, "ManajerOfPeopleWhoHaveMortgages", dll.

Saya rasa itu benar bahwa satu kelas Manajer monolitik tidak desain yang baik, tetapi menggunakan 'Manajer' tidak buruk. Alih-alih UserManager kami mungkin memecahnya menjadi UserAccountManager, UserProfileManager, UserSecurityManager, dll.

'Manajer' adalah kata yang baik karena jelas menunjukkan kelas tidak mewakili 'hal' dunia nyata. 'AccountsClerk' - bagaimana saya bisa tahu jika itu adalah kelas yang mengelola data pengguna, atau mewakili seseorang yang merupakan Accounts Clerk untuk pekerjaan mereka?


31
2017-12-08 13:12



Karena Anda tertarik dengan artikel di bidang ini, Anda mungkin tertarik dengan artikel opini Steve Yegge "Eksekusi dalam Kerajaan Nouns":

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


19



Ketika saya menemukan diri saya berpikir tentang menggunakan Manager atau Helper dalam nama kelas, saya menganggapnya sebagai bau kode yang berarti saya belum menemukan abstraksi yang tepat dan / atau saya melanggar prinsip tanggung jawab tunggal, sehingga refactoring dan menempatkan lebih banyak usaha dalam desain sering membuat penamaan lebih mudah.

Tetapi bahkan kelas yang dirancang dengan baik tidak (selalu) menamai diri mereka sendiri, dan pilihan Anda sebagian bergantung pada apakah Anda membuat kelas model bisnis atau kelas infrastruktur teknis.

Kelas model bisnis bisa sulit, karena mereka berbeda untuk setiap domain. Ada beberapa istilah yang saya gunakan banyak, seperti Policy untuk kelas strategi dalam domain (misalnya, LateRentalPolicy), tetapi ini biasanya mengalir dari mencoba membuat "di mana-mana bahasa"yang dapat Anda bagikan dengan pengguna bisnis, merancang dan memberi nama kelas sehingga mereka memodelkan ide dunia nyata, objek, tindakan, dan acara.

Kelas infrastruktur teknis sedikit lebih mudah, karena mereka mendeskripsikan domain yang kami ketahui dengan sangat baik. Saya lebih suka memasukkan nama pola desain ke dalam nama kelas, seperti InsertUserCommand,  CustomerRepository, atau SapAdapter. Saya memahami kekhawatiran tentang mengkomunikasikan implementasi daripada niat, tetapi pola desain mengawinkan dua aspek desain kelas ini - setidaknya ketika Anda berurusan dengan infrastruktur, di mana Anda ingin implementasinya Desain menjadi transparan bahkan saat Anda menyembunyikan detailnya.


16



Menjadi au fait dengan pola sebagaimana didefinisikan oleh (katakanlah) Buku GOF, dan memberi nama objek setelah ini membuat saya jauh dalam penamaan kelas, mengatur mereka dan mengkomunikasikan maksud. Kebanyakan orang akan memahami nomenklatur ini (atau setidaknya sebagian besar darinya).


8