Bisakah kelas manajer menjadi tanda arsitektur yang buruk?

Akhir-akhir ini saya mulai berpikir bahwa memiliki banyak kelas manajer dalam desain Anda adalah hal yang buruk. Gagasan itu belum cukup matang bagi saya untuk membuat argumen yang meyakinkan, tetapi inilah beberapa poin umum:

• Saya merasa jauh lebih sulit bagi saya untuk memahami sistem yang sangat bergantung pada "manajer". Ini karena, selain komponen program yang sebenarnya, Anda juga harus memahami bagaimana dan mengapa manajer digunakan.

• Manajer, sering kali, tampaknya digunakan untuk meringankan masalah dengan desain, seperti ketika programmer tidak dapat menemukan cara untuk membuat program Just Work ^TM dan harus bergantung pada kelas manajer untuk membuat semuanya beroperasi dengan benar.

Tentu saja, mangers bisa baik. Contoh yang jelas adalah EventManager, salah satu konstruksi favorit saya sepanjang masa. : P Maksud saya adalah bahwa manajer tampaknya terlalu sering digunakan, dan tanpa alasan selain menutupi masalah dengan arsitektur program.

Apakah kelas manajer benar-benar merupakan tanda arsitektur yang buruk?

Kelas manajer dapat menjadi tanda arsitektur yang buruk, karena beberapa alasan:

• Pengidentifikasi Berarti

  Nama FooManagertidak mengatakan apa-apa tentang apa yang sebenarnya dilakukan kelas , kecuali bahwa itu entah bagaimana melibatkan Fooinstance. Memberi kelas nama yang lebih bermakna menjelaskan tujuan sebenarnya, yang kemungkinan akan mengarah pada refactoring.

• Tanggung jawab fraksional

  Menurut prinsip tanggung jawab tunggal, setiap unit kode harus melayani tepat satu tujuan. Dengan seorang manajer, Anda mungkin secara artifisial membagi tanggung jawab itu.

  Pertimbangkan a ResourceManageryang mengoordinasikan masa hidup, dan akses ke, Resourcekejadian. Aplikasi memiliki satu ResourceManagermelalui mana ia memperoleh Resourceinstance. Dalam hal ini tidak ada alasan nyata mengapa fungsi ResourceManagerinstance tidak dapat dilayani oleh metode statis di Resourcekelas.

• Abstraksi Tidak Terstruktur

  Seringkali seorang manajer diperkenalkan untuk mengabstraksi masalah mendasar dengan objek yang dikelolanya. Inilah sebabnya mengapa manajer cenderung menggunakan kekerasan sebagai band-aids untuk sistem yang dirancang dengan buruk. Abstraksi adalah cara yang baik untuk menyederhanakan sistem yang kompleks, tetapi nama "manajer" tidak memberikan petunjuk mengenai struktur abstraksi yang diwakilinya. Apakah ini benar-benar sebuah pabrik, atau proxy, atau sesuatu yang lain?

Tentu saja, manajer dapat digunakan untuk lebih dari sekadar kejahatan, dengan alasan yang sama. Sebuah EventManager— yang benar-benar sebuah — Dispatchermenyebabkan peristiwa dari sumber dan mengirimkannya ke target yang berminat. Dalam hal ini masuk akal untuk memisahkan tanggung jawab menerima dan mengirim acara, karena seseorang Eventhanya pesan tanpa gagasan asal atau tujuan.

Kami menulis Dispatcherdari Eventcontoh untuk dasarnya alasan yang sama kita menulis GarbageCollectoratau Factory:

Seorang manajer tahu muatan apa yang seharusnya tidak perlu diketahui.

Saya pikir, itulah pembenaran terbaik yang ada untuk menciptakan kelas seperti manajer. Ketika Anda memiliki beberapa objek "payload" yang berperilaku seperti nilai, itu harus sebodoh mungkin sehingga keseluruhan sistem tetap fleksibel. Untuk memberikan makna pada setiap instance, Anda membuat manajer yang mengoordinasikan instance tersebut dengan cara yang bermakna. Dalam situasi lain apa pun, manajer tidak perlu.

Manajer dapat menjadi tanda arsitektur yang buruk, tetapi lebih sering daripada tidak, mereka hanya merupakan tanda ketidakmampuan atas nama perancang untuk menghasilkan nama yang lebih baik untuk objeknya, atau hanya sekadar cerminan dari fakta bahwa bahasa Inggris (dan bahasa manusia apa pun dalam hal ini) cocok untuk mengkomunikasikan konsep praktis setiap hari, dan bukan konsep yang sangat abstrak dan sangat teknis.

Contoh sederhana untuk mengilustrasikan poin saya: sebelum Pola Pabrik dinamai, orang-orang menggunakannya, tetapi mereka tidak tahu bagaimana menyebutnya. Jadi, seseorang yang harus menulis sebuah pabrik untuk Fookelasnya mungkin telah menyebutnya FooAllocationManager. Itu bukan desain yang buruk, itu hanya kurangnya imajinasi.

Dan kemudian seseorang perlu menerapkan kelas yang mengelola banyak pabrik dan membagikannya ke berbagai objek yang meminta mereka; dan dia menyebut kelasnya FactoryManagerkarena kata itu Industrytidak pernah terpikir olehnya, atau dia pikir itu tidak keren karena dia belum pernah mendengar sesuatu seperti itu dalam pemrograman. Sekali lagi, kasus kurangnya imajinasi.

Memiliki banyak kelas "manajer" sering merupakan gejala dari model domain anemik , di mana logika domain dikeluarkan dari model domain dan alih-alih ditempatkan di kelas manajer, yang kurang lebih menyamakan dengan skrip transaksi . Bahayanya di sini adalah bahwa Anda pada dasarnya kembali ke pemrograman prosedural - yang dengan sendirinya mungkin atau mungkin tidak menjadi hal yang baik tergantung pada proyek Anda - tetapi kenyataan bahwa itu tidak dipertimbangkan atau dimaksudkan adalah masalah sebenarnya.

Mengikuti prinsip "pakar informasi" , operasi logis harus berada sedekat mungkin dengan data yang diperlukan. Ini berarti memindahkan logika domain kembali ke model domain, sehingga operasi logis inilah yang memiliki efek yang dapat diamati pada keadaan model domain, daripada 'manajer' mengubah keadaan model domain dari luar.

Jawaban singkat: itu tergantung .

Ada beberapa bentuk "kelas manajer" yang berbeda, beberapa di antaranya bagus, beberapa lainnya buruk, dan bagi sebagian besar mereka sangat tergantung pada konteksnya jika memperkenalkan kelas manajer adalah hal yang benar. Titik awal yang baik untuk membuat mereka benar adalah dengan mengikuti prinsip tanggung jawab tunggal - jika Anda tahu persis apa yang bertanggung jawab atas masing-masing kelas manajer Anda (dan apa yang tidak), Anda akan memiliki lebih sedikit masalah dalam memahami mereka.

Atau untuk menjawab pertanyaan Anda secara langsung: ini bukan jumlah kelas manajer yang menunjukkan arsitektur yang buruk, tetapi memiliki terlalu banyak dari mereka dengan tanggung jawab yang tidak jelas, atau menangani terlalu banyak masalah.

Meskipun mungkin mudah untuk mengatakan bahwa mereka secara inheren menunjukkan desain yang buruk, mereka dapat berfungsi untuk membawa banyak hal baik dan mengurangi kompleksitas kode dan kode boilerplate lainnya di seluruh proyek dengan mencakup satu tugas dan tanggung jawab secara universal.

Sementara prevalensi Manajer mungkin karena penilaian yang buruk pada desain, mereka juga dapat menangani keputusan desain yang buruk atau masalah ketidakcocokan dengan komponen lain dalam desain komponen atau komponen UI pihak ketiga, atau layanan web pihak ketiga dengan antarmuka yang aneh sebagai contoh.

Contoh-contoh ini menunjukkan di mana mereka sangat berguna untuk situasi tertentu dalam mengurangi kompleksitas keseluruhan dan mempromosikan kopling longgar antara berbagai komponen dan lapisan dengan merangkum "kode jelek" di satu tempat. Namun satu hal yang membuat orang tergoda untuk menjadikan Manajer sebagai orang lajang, saya akan menyarankan hal ini, dan tentu saja seperti yang orang lain sarankan, Prinsip Tanggung Jawab Tunggal harus selalu diikuti.

Bisakah kelas manajer menjadi tanda arsitektur yang buruk?

Anda menjawab pertanyaan Anda: mereka tidak harus menjadi tanda desain yang buruk.

Kecuali untuk contoh dalam pertanyaan Anda dengan EventManager, ada contoh lain: dalam pola desain MVC , presenter dapat dilihat sebagai manajer untuk kelas model / tampilan.

Namun, jika Anda menyalahgunakan konsep, maka itu adalah tanda desain yang buruk dan mungkin arsitektur.

Ketika kelas memiliki "Manajer" dalam nama, waspadalah terhadap masalah kelas dewa (satu dengan terlalu banyak tanggung jawab). Jika sulit untuk menggambarkan apa yang bertanggung jawab atas kelas dengan namanya, itu adalah tanda peringatan desain.

Selain kelas manajer yang buruk, nama terburuk yang pernah saya lihat adalah "DataContainerAdapter"

"Data" harus merupakan salah satu dari substring yang dilarang dalam nama-itu semua data, "data" tidak memberi tahu Anda banyak di sebagian besar domain.

Kelas manajer - seperti hampir semua kelas yang diakhiri dengan "-er" - adalah jahat dan tidak ada hubungannya dengan OOP. Jadi bagi saya itu pertanda arsitektur yang buruk.

Mengapa? Nama "-er" menyiratkan bahwa perancang kode mengambil beberapa tindakan dan mengubahnya ke kelas. Sebagai hasilnya, kami memiliki entitas buatan yang tidak mencerminkan konsep nyata, tetapi beberapa tindakan. Ini terdengar sangat prosedural.

Selain itu, biasanya kelas-kelas tersebut mengambil beberapa data dan mengoperasikannya. Ini adalah filosofi data pasif dan prosedur aktif dan menemukan tempatnya dalam pemrograman prosedural. Jika Anda menyadarinya, tidak ada yang buruk di kelas Manajer, tapi itu bukan OOP.

Pemikiran objek menyiratkan bahwa objek melakukan sesuatu untuk diri mereka sendiri. Temukan domain Anda , bangun jaring semantik , biarkan benda Anda menjadi organisme hidup, manusia cerdas dan bertanggung jawab.

Objek seperti itu tidak perlu dikontrol. Mereka tahu apa yang harus dilakukan dan bagaimana melakukannya. Jadi kelas Manajer melanggar prinsip OOP dua kali. Selain sebagai kelas "-er", ia mengontrol objek lain. Tapi itu tergantung pada manajernya. Ia mengendalikan - ia adalah manajer yang buruk. Jika dia berkoordinasi - dia adalah manajer yang baik. Itu sebabnya surat "C" di MVC harus dieja sebagai "Koordinator".

Jawaban yang benar untuk pertanyaan ini adalah:

1. Tergantung.

Setiap situasi yang akan Anda temui saat menulis perangkat lunak berbeda. Mungkin Anda berada di tim di mana semua orang tahu bagaimana kelas manajer bekerja secara internal? Akan sangat gila untuk tidak menggunakan desain itu. Atau jika Anda mencoba mendorong desain manajer ke orang lain, dalam hal ini mungkin itu ide yang buruk. Tapi itu tergantung pada detail yang tepat.