Bagaimana menghindari ... Pembantu atau ... Kelas manajer

Saya memiliki beberapa kelas Pembantu di proyek saya. Saya telah membaca bahwa ini adalah hal yang buruk, tetapi saya curiga bahwa "Helper" adalah sufiks yang salah bagi mereka. Saya akan memberi contoh.

Pertama, saya punya Userkelas. Saya perlu metode GetSuggestedFriends()untuk pengguna. Saya ingin menjaga logika untuk menentukan daftar teman yang disarankan keluar dari Userkelas, sehingga tidak membengkak. Saat ini, saya memiliki FriendshipHelperyang menerima Userdalam konstruktornya. Ini berisi logika untuk mendapatkan teman yang disarankan, dan sekarang saya dapat menelepon myUser.FriendshipHelper.GetSuggestedFriends().

Awalnya hanya FriendshipHelpermemiliki metode statis, dan sebuah Userobjek diteruskan ke masing-masing. Jika saya menulis kelas dari awal sekarang, mungkin saya akan menyebutnya FriendshipManager- itu juga melakukan hal-hal seperti menambah dan menghapus teman.

Saya juga pernah membaca bahwa ...Managerkelas itu buruk. Apa yang harus saya sebut kelas ini? Atau, apakah ini "kode buruk"? Di mana logika untuk mendapatkan teman yang disarankan, teman saat ini, dan menambah dan menghapus teman secara langsung? Tentunya tidak semua di Userkelas raksasa ?

object-oriented-design clean-code

— pengguna1002973
sumber

Di mana kode ini tinggal? Apakah ini layanan? Apakah itu mengakses penyimpanan data? Ini adalah UI untuk melakukan hal-hal teman-y ini?

— Telastyn

Setelah Anda menyingkirkan semua metode statis dan menemukan rumah yang nyata dalam desain OOP Anda, kelas-kelas ini benar-benar bukan kelas pembantu, jadi jangan ragu untuk mengganti nama. Tidak ada yang salah dengan Manajer Persahabatan jika Anda perlu mengelola pertemanan di proyek Anda.

— JeffO

Ada apa dengan ini Facebook?

— toniedzwiedz

Kemungkinan duplikat Mana yang merupakan praktik yang lebih baik - metode pembantu sebagai contoh atau statis?

— nyamuk

Jawaban:

Bagaimana menghindari ... Pembantu atau ... Kelas manajer «

Secara umum: dengan Desain yang bagus

Pertama, saya memiliki kelas Pengguna. Saya memerlukan metode GetSuggestedFriends () untuk pengguna.

Iya. A user memiliki hubungan dengan yang lain users. Dan hubungan tersebut dapat dinyatakan sebagai metode user, misalnya user.isFriend(user2). Ini adalah tanggung jawab userproyek. Selain itu, Anda meminta objek lain untuk membantu menemukan teman lain . Anda mendelegasikan tanggung jawab untuk menemukan teman ke objek lain dan itu cukup baik .

Saat ini, saya memiliki FriendshipHelper yang menerima Pengguna dalam konstruktornya. Ini berisi logika untuk mendapatkan teman yang disarankan, dan sekarang saya dapat menghubungi myUser.FriendshipHelper.GetSuggestedFriends ()

Yang tidak per se buruk, tapi memiliki satu kelemahan: inisialisasi "Penolong" dengan satu userbatas kemungkinan untuk yang satu user.

Yang Anda butuhkan adalah objek , yang membantu menemukan teman ke pengguna mana pun . Jadi metode generik akan masuk akal: userMatcher.findFriendsFor(user)yang pada kembali memberikan koleksi dari teman yang mungkin ( user).

Jika saya menulis kelas dari awal sekarang, mungkin saya akan menyebutnya Persahabatan Manajer

Masalah Anda bukan menulis "kelas pembantu", tetapi menemukan nama yang tepat . ;)

itu juga melakukan hal-hal seperti menambah dan menghapus teman.

Itu desain yang salah . Ambil contoh: Apakah ibu Anda menambahkan teman ke hidup Anda atau apakah Anda menambahkan mereka sendiri?

Tentu saja koleksi dari teman-teman adalah milik usersendiri dan begitu juga metode user.addFriend(user)atauuser.removeFriend(user)

Apa yang harus saya sebut kelas ini?

Seperti yang dikatakan sebelumnya: Anda hanya memiliki masalah penamaan dan "pembantu" Anda baik - baik saja . Tetapi Anda harus berpikir lebih hati-hati tentang tanggung jawab masing-masing objek.

Di mana logika untuk mendapatkan teman yang disarankan, teman saat ini, dan menambah dan menghapus teman secara langsung? Tentunya tidak semua di kelas Pengguna raksasa

Tidak. Ini adalah dua pekerjaan yang Anda perlukan satu objek terpisah , seperti dalam kehidupan nyata di mana Anda memiliki orang dan agen kencan .

— Thomas Junk
sumber

Penjelasan yang bagus, tetapi Anda jelas tidak pernah bertemu ibu saya. : '(

— Matt

@ HEATH3N Saya harap, itu tidak mempengaruhi kemampuan pemodelan perangkat lunak Anda.

— Thomas Junk

Saya menyarankan agar Anda memiliki FriendshipServicekelas yang memiliki metode (non-statis) GetSuggestedFriends(User). Hindari metode statis karena Anda tidak dapat mengimplementasikan antarmuka yang membuatnya lebih sulit untuk diuji. Hindari menambahkan objek pengguna ke konstruktor karena Anda mungkin ingin memperluas FriendshipService Anda dengan metode yang tidak secara spesifik terkait dengan satu pengguna. (Misalnya, Anda mungkin ingin menyarankan teman ke sekelompok pengguna, atau menyarankan teman berdasarkan sesuatu yang lain)

Seorang pengguna kemungkinan besar tidak akan menyadari FriendshipService(karena Pola Tanggung Jawab Tunggal)

— Bjorn
sumber

Mengubah akhiran dari "Helper" menjadi "Service" tidak membuatnya lebih mudah untuk mendapatkan gagasan tentang tanggung jawab kelas dengan namanya, yang saya pikir adalah inti dari pertanyaan.

— Mike Partridge

Ya, nama itu sendiri mungkin tidak mengatakan banyak, tetapi saya akan mengatakan bahwa menggunakan akhiran "Layanan" adalah cara yang lebih standar untuk berkomunikasi bahwa kelas melakukan semacam logika canggih. Kelas "Helper" biasanya (paling tidak menurut pengalaman saya) biasanya lebih terkait dengan tugas yang sangat sederhana, seperti pemformatan sederhana dan metode statis kecil. Saya berharap bahwa Anda dapat mengganti "Layanan" -perkenalan dengan implementasi yang berbeda. Lebih lanjut, ada banyak pertanyaan di sini, tidak hanya penamaan.

— Bjorn

Sepakat. Ketiga "Pembantu", "Manajer", dan "Layanan" adalah cara kami mengelompokkan metode untuk menghindari berton-ton kelas super-spesifik dengan metode tunggal, tetapi "Layanan" memiliki makna yang sedikit lebih, seperti yang Anda gambarkan. Saya akan menambahkan bahwa ini menyiratkan bahwa kelas adalah bagian dari antarmuka lapisan layanan, membantu menyederhanakan akses ke logika bisnis (yang dapat terdiri dari banyak kelas yang lebih spesifik) untuk kelas domain tertentu. Apakah logika saran harus dalam kelas yang terpisah dari logika tambahkan / hapus tergantung pada seberapa rumit penerapan logika saran.

— Mike Partridge

Ketika kita menamai kelas ThingManager atau ThingService kita membuka pintu untuk membuat kelas yang tumbuh di luar kendali. Karena namanya tidak dengan jelas menunjukkan sesuatu yang spesifik yang termasuk dalam kelas, itu tidak mengecualikan apa pun juga. Saya perlu metode baru yang berhubungan dengan Hal. Kemana perginya? Idk, letakkan di ThingManager dengan semua metode lainnya.

— Scott Hannen