Apakah mudah ditemukannya pengembang saat menggunakan prinsip SOLID?

Saya mengerjakan berbagai aplikasi bisnis di mana semua pengembang lain terbiasa melakukan aplikasi CRUD dasar atau hanya berfokus pada membuat antarmuka yang cantik / fungsional dan saya mendapatkan banyak hal sebagai berikut.

"Dengan cara yang kita gunakan untuk melakukannya, Karyawan akan memiliki semua hal yang dapat Anda lakukan dengan seorang karyawan." Dan itu benar. "Kelas" yang satu itu memiliki ribuan baris kode dan apa pun yang dapat Anda lakukan dengan seorang karyawan ada di sana. Atau, lebih buruk lagi, ada tabel data karyawan dan masing-masing pengembang menemukan cara untuk melakukan apa yang ingin mereka lakukan dalam event handler.

Semua hal buruk tentang pendekatan itu benar tetapi setidaknya pengembang yang menggunakan karyawan dapat, tanpa pergi ke dokumen lain, mencari tahu cara mendaftarkan karyawan dalam rencana kesehatan, memberikan kenaikan gaji, memecat, menyewa, mentransfer dll. untuk Manajer dan semua ide utama lainnya. Atau, jika mereka menggunakan karyawan tabel data lain yang dibutuhkan, bisa saja melakukan apa yang mereka inginkan.

Ya, ada banyak kode duplikat. Ya itu kode yang sangat rapuh. Ya pengujian itu jauh lebih sulit daripada yang diperlukan. Ya, mengubah fungsionalitas disebabkan oleh rasa takut dan Salin Tempel adalah alami karena pendekatannya.

Tetapi mereka setidaknya dapat menemukan apa yang tersedia dengan membuat satu kelas atau mereka dapat melakukan apa yang perlu mereka lakukan tanpa harus memahami perbedaan antara antarmuka, kelas abstrak, kelas beton dll. Dan mereka tidak perlu mencari apa pun selain dari metode yang dikembalikan oleh intellisense atau mengetahui tabel tempat data berada.

Saya telah googled / binged dan bahkan yahoo! D tetapi saya belum menemukan pengakuan atas masalah ini.

Jadi mungkin tidak ada masalah dan saya hanya melewatkan sesuatu. Saya telah memutar otak untuk mencari solusi di mana pengembang yang tidak bekerja dengan perilaku / desain yang sebenarnya dapat dengan mudah menemukan cara melakukan sesuatu tanpa harus merujuk dokumen eksternal atau memindai nama kelas dalam berbagai komponen / proyek untuk menemukan yang terdengar seperti itu akan berhasil.

Satu-satunya hal yang saya dapat buat adalah memiliki ini, karena kurangnya nama yang lebih baik, "Daftar Kelas Konten" yang tidak lebih dari yang mengembalikan kelas yang sebenarnya (dan sebenarnya sebagian besar dari mereka adalah antarmuka tetapi mereka tidak tahu bedanya atau bahkan peduli) yang dapat digunakan pengembang lain untuk melakukan tugas aktual yang diinginkan. Masih berakhir dengan kelas yang sangat besar tetapi hampir tidak ada perilaku di dalamnya.

Apakah ada cara yang lebih baik yang tidak memerlukan pengetahuan intim dari tingkat menengah di mana implementasi SOLID sebenarnya terjadi?

Pada dasarnya yang saya tanyakan adalah ada cara untuk memungkinkan pengembang tipe CRUD terus menjadi pengembang CRUD dalam sistem yang sangat kompleks

Tampaknya apa yang Anda jelaskan (yaitu kelas Karyawan memiliki SEMUA kode yang mungkin dapat Anda lakukan dengan seorang karyawan) adalah pola yang sangat umum yang secara pribadi saya lihat cukup banyak. Beberapa kode yang saya tulis sendiri sebelum saya tahu lebih baik.

Apa yang dimulai sebagai kelas yang seharusnya mewakili entitas tunggal dengan serangkaian metode yang dapat dikelola, berubah menjadi sesuatu yang merupakan mimpi buruk untuk dipertahankan karena setiap fitur dan setiap rilis terus menambahkan semakin banyak ke kelas yang sama. Ini bertentangan dengan prinsip-prinsip SOLID yang mengatakan Anda harus menulis kelas sekali dan menahan keinginan untuk memodifikasinya berulang-ulang.

Beberapa waktu yang lalu (sebelum saya menemukan pola desain atau SOLID seperti yang dipromosikan oleh orang lain), saya memutuskan untuk proyek berikutnya untuk sedikit membalikkan keadaan. Saya sedang mengerjakan server yang berfungsi sebagai antarmuka antara dua platform yang sangat besar. Pada awalnya, hanya sinkronisasi konfigurasi yang diperlukan, tetapi saya dapat melihat bahwa ini akan menjadi tempat yang logis untuk banyak fitur lainnya.

Jadi alih-alih menulis kelas yang mengekspos metode, saya menulis kelas yang mewakili metode (ternyata pola "Perintah" dari GoF). Alih-alih melakukan pekerjaan untuk klien, semua kelas aplikasi utama saya menjadi pemegang status persisten dan mereka menjadi lebih pendek. Setiap kali saya harus menambahkan metode antarmuka baru ke layanan itu sendiri, saya hanya akan membuat kelas baru yang memiliki metode Execute () yang memulai semuanya. Jika beberapa perintah memiliki sesuatu yang sama, mereka berasal dari kelas dasar yang sama. Akhirnya hal itu memiliki 70+ kelas perintah yang berbeda dan seluruh proyek masih sangat mudah dikelola dan sebenarnya menyenangkan untuk dikerjakan.

"Kelas TOC" Anda tidak jauh dari apa yang saya lakukan. Saya memiliki pabrik abstrak (GoF) yang bertanggung jawab atas instantiating perintah. Di dalam kelas pabrik, saya menyembunyikan sebagian besar detail di belakang kelas dasar dan makro gaya ATL, jadi ketika seorang programmer harus menambah atau mencari permintaan, mereka masuk ke sana dan yang mereka lihat hanyalah:

BEGIN_COMMAND_MAP()
    COMMAND_ENTRY( CChangeDeviceState )
    COMMAND_ENTRY( CSetConfiguration )
    ....
END_COMMAND_MAP()

Sebagai alternatif (atau sebagai tambahan), Anda dapat menempatkan semua kelas perintah aktual Anda ke ruang nama yang terpisah sehingga ketika orang-orang melakukan pengkodean dan perlu menjalankan sesuatu, mereka cukup mengetik nama namespace dan Intellisense mendaftar semua perintah yang telah Anda tetapkan. Kemudian setiap perintah mencakup semua metode get get / set yang menentukan dengan tepat parameter input dan output apa.

Anda juga dapat menjelajahi penggunaan pola Facade (GoF). Alih-alih mengekspos 1000+ kelas untuk insinyur CRUD Anda. Sembunyikan mereka semua di belakang satu kelas yang hanya memperlihatkan apa yang dibutuhkan. Saya masih tetap berpegang teguh pada setiap "aksi" menjadi kelasnya sendiri, tetapi kelas Facade Anda dapat memiliki metode yang akan membuat setiap tindakan Anda dan sekali lagi, dengan Intellisense mereka akan segera melihat apa yang tersedia. Atau memiliki Facade memiliki metode aktual, tetapi secara internal membuatnya instantiate perintah, antri mereka dan menunggu tanggapan. Kemudian kembalilah seolah-olah pemanggilan metode biasa dilakukan.

(*) Saya tidak ingin membahas terlalu banyak detail, tetapi saya sebenarnya memiliki kelas "Command" dan "CommandHandler". Ini memisahkan tanggung jawab mengelola / mengantri / membuat serial parameter masuk / keluar dari kelas yang benar-benar "menangani" perintah-perintah itu.

Itu bisa menjadi masalah. Terutama jika Anda menyebutkan banyak hal dengan buruk. Tetapi ada sejumlah solusi untuk itu tanpa menggunakan kelas yang kompleks. Heck, kelas dengan terlalu banyak metode bisa sama sulitnya untuk dinavigasi dengan Intellisense.

Coba gunakan namespaces (C #) atau paket (Java), atau konsep serupa apa pun yang dimiliki bahasa Anda (saya akan merujuk semuanya sebagai ruang nama), untuk menyederhanakan masalah.

Mulailah dengan nama perusahaan Anda. Itu membatasi Intellisense hanya ruang nama yang ditulis sendiri. Kemudian, jika Anda memiliki beberapa aplikasi, gunakan bagian kedua namespace untuk memisahkannya. Sertakan Core namespace, untuk hal-hal yang ada di seluruh aplikasi. Selanjutnya memecah hal-hal menjadi jenis fungsionalitas. Dan seterusnya.

Jika Anda melakukan ini dengan benar, Anda akan mendapatkan item yang sangat mudah ditemukan.

Untuk mengambil contoh Anda, jika saya ingin validasi Pengguna, saya ketik "MyCo." dan itu memberi saya daftar ruang nama aplikasi. Saya tahu basis data Pengguna digunakan di semua aplikasi kami, jadi saya ketik "Core." maka saya mendapatkan daftar jenis fungsionalitas. Salah satunya adalah "Validasi" sehingga sepertinya pilihan yang jelas. Dan di sana, di dalam Validasi, ada "UserValidator" dengan semua fungsinya.

Ketika hal itu terjadi, untuk hal-hal yang sering saya gunakan, saya akan segera mengingat nama-namanya, atau setidaknya konvensi. Karena saya membuat banyak perubahan pada aturan validasi, saya akan tahu bahwa semua kelas validasi saya disebut FooValidator, di mana Foo adalah nama tabel. Jadi saya sebenarnya tidak perlu melintasi ruang nama. Saya hanya akan mengetik UserValidator dan membiarkan IDE melakukan sisa pekerjaan.

Tetapi untuk hal-hal yang saya tidak ingat, masih cukup mudah untuk menemukannya. Dan ketika saya melakukannya, saya bisa menghapus awalan namespace.

Karena Anda merujuk mereka sebagai pengembang "CRUD" pada dasarnya, kami akan menganggap Anda tidak menganggapnya sangat baik. Kami tidak tahu apakah ini berarti mereka juga tidak memahami domain bisnis Anda. Jika mereka memahami domain, kelas-kelas harus masuk akal bagi mereka. Mengetahui beberapa kelas telah dibangun, mereka harus melihat dulu, bertanya kedua, mempertimbangkan membangun dari awal sebagai opsi ketiga.

Sejauh mengetahui cara mengetahui secara otomatis cara menggunakan / menggunakan kembali suatu kelas hanya dengan melihatnya seharusnya tidak diharapkan pertama kali. Anda harus mendokumentasikan dan mungkin memberikan penjelasan tambahan baik melalui pelatihan atau mungkin selama peninjauan kode.

Banyak proyek API dan sumber terbuka menyediakan dokumentasi, contoh kode, dan penjelasan lainnya. Anda mungkin tidak perlu ramah pengguna, tetapi tidak ada cara lain. Ajari mereka dengan baik.