Kiat / saran tentang cara mengurangi penggunaan kelas "manajer"?

Saya kadang-kadang mendengar bahwa memiliki terlalu banyak "manajer" kelas dalam desain program Anda adalah bau kode dan menambah lapisan kompleksitas yang tidak perlu. Bagi saya masuk akal bahwa orang ingin menggunakan kelas manajer untuk memanipulasi dan mengendalikan objek dari konteks yang masuk akal bagi mereka, tetapi mencari tahu bagaimana membuat solusi bekerja tanpa mereka dapat membingungkan.

Haruskah seseorang benar-benar menghindari kelas manajer sebanyak mungkin? Juga, artikel / makalah apa yang harus saya baca tentang bagaimana menerapkan alternatif kerja untuk kasus umum / umum di mana manajer ini dapat dihapus?

Mungkin ada dua alasan mengapa ini bau kode. Salah satu alasannya adalah, itu mungkin berarti Anda tidak memiliki objek domain tetapi Anda memiliki objek nilai yang hanya menyimpan data untuk dimanipulasi oleh kelas pengontrol atau manajer. Ini sebenarnya cukup umum dan sama dengan pemrograman prosedural dalam bahasa OO. "Banyak manajer" mungkin merupakan petunjuk bahwa Anda perlu mengintegrasikan logika negara, validasi, dan masalah langsung lainnya ke objek domain sehingga mereka benar-benar merangkum sesuatu. Tentu saja ada petunjuk yang lebih besar seperti fakta bahwa Anda tidak memiliki metode selain pengambil / setter.

Alasan lain mengapa ini adalah bau kode adalah mungkin itu berarti objek domain Anda tidak benar-benar berhubungan satu sama lain dengan sangat baik. Misalnya, jika Anda memiliki kelas Akun yang benar-benar tidak tahu apa-apa tentang kelas Transaksi kecuali bahwa itu bernama Transaksi dan mungkin ada lebih dari satu, maka Anda sekali lagi Anda tidak benar-benar memiliki implementasi domain bisnis yang sangat bersemangat. Misalnya SavingsAccount mungkin harus tahu bahwa itu tidak dapat menerima Transaksi Debit jika statusStatus ditutup. Banyak implementasi yang menyerahkannya kepada manajer.

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 imo "bau kode".

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 skrip transaksi yang mengubah keadaan model domain dari luar.

Masalah terbesar dengan Kelas Manajer adalah bahwa mereka hanya mewakili ide yang tidak jelas tentang apa yang seharusnya dilakukan oleh kelas. Jika Anda menyebut sesuatu sebagai Manajer maka ia dapat melakukan apa saja dan segala sesuatu yang berkaitan dengan apa pun yang dikelola. Saya kira dalam beberapa konteks itu mungkin baik-baik saja, tetapi saya akan mengatakan dalam hampir semua kasus itu bukan apa yang Anda inginkan. Anda ingin seseorang dapat melihat nama kelas dan tidak hanya memiliki ide bagus tentang apa yang dilakukan kelas tetapi juga apa yang tidak dilakukan.

Masalah lain dengan kelas manajer adalah bahwa hal itu membuatnya sangat sulit untuk memutuskan ke mana fungsi harus pergi. Ketika ada banyak kelas manajer maka seringkali ada banyak tumpang tindih dalam fungsionalitas antara kelas manajer. Anda kemudian harus mencari tahu kelas mana yang harus mengimplementasikan fungsionalitas yang tumpang tindih dan tentu saja orang lain akan memilih secara berbeda. Jadi ketika mereka mencari fungsionalitas dan tidak melihatnya di tempat yang mereka harapkan, maka mereka melanjutkan dan mengimplementasikannya kembali di tempat yang mereka pikir sebagai milik mereka karena mereka tidak mengetahui keberadaan implementasi lainnya. Dengan kata lain, kelas manajer mengarah pada desain yang sulit dipahami dan sering berbelit-belit.