Bagaimana Anda mendekati desain kelas di OOP?

Ketika saya mencoba merancang solusi OO, saya biasanya menggunakan pemodelan CRC di mana saya mencantumkan nama kelas (kata benda), apa yang mereka lakukan (kata kerja) dan bagaimana mereka berkolaborasi dengan kelas lain.

Blog ini memiliki hal di bawah ini untuk dikatakan tentang pendekatan kata benda ini

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

Pertanyaan saya adalah, apakah ada teknik pemodelan yang lebih baik untuk menggunakan pendekatan OO?

Dalam keadilan, dia menambahkan "Bersenang-senang" ke klaim itu.

Sampai hari ini, saya cenderung memulai dengan memodelkan sistem menggunakan pendekatan "kata benda dan kata kerja", tetapi saya telah menemukan selama bertahun-tahun bahwa TDD mengajarkan kita bahwa pendekatan ini menarik fokus Anda ke hal yang salah. Dalam hal ini, blogger benar. Namun, saya tidak yakin bahwa itu adalah pendekatan yang salah, daripada cara pikiran kita bekerja.

Jika Anda ingin mencoba sedikit tantangan di sini, berhenti membaca dan coba model permainan Monopoli, menggunakan bahasa Inggris, lalu kembali ke sini.

Saya curiga godaannya adalah untuk segera melihat benda-benda yang sering berinteraksi dengan kita - papan, ruang, kartu, dadu, potongan-potongan - tetapi itu bukanlah tempat di mana sebagian besar logika mengalir. Sebagian besar benda-benda ini sepenuhnya bodoh. Data, jika Anda mau.

Tapi begitu Anda mulai menulis tes, Anda menyadari objek mana yang sejauh ini paling penting dalam permainan apa pun: aturan.

Ingat kertas kecil yang pernah Anda baca saat pertama kali mendapatkan permainan dan tidak berinteraksi lagi sampai ada perselisihan? Versi terkomputerisasi tidak beroperasi seperti itu. Setiap hal yang pemain coba lakukan, komputer akan berkonsultasi dengan aturan dan melihat apakah mereka diizinkan melakukannya atau tidak.

Ketika Anda memikirkannya, Anda melakukan hal yang sama tetapi karena butuh waktu untuk membaca aturan berbasis kertas dan otak Anda memiliki sistem caching yang masuk akal, Anda berkonsultasi dengan aturan di kepala Anda. Sebuah komputer mungkin akan merasa mudah untuk membaca kembali peraturan - kecuali jika disimpan dalam basis data, dalam hal ini mungkin akan menyimpannya juga.

Dan inilah mengapa TDD sangat populer untuk desain mengemudi sebenarnya. Karena itu cenderung mendorong proses berpikir Anda dengan cepat ke tempat yang tepat:

Ketika saya berpikir bahwa saya akan menulis beberapa tes untuk permainan Monopoli saya. Saya mungkin melihat set saya dan mencoba menemukan objek. Jadi, kami punya potongan-potongan ini. Saya akan menulis beberapa tes untuk itu.

Mungkin saya akan memiliki kelas dasar MonopolyPiece dan setiap jenis karya akan berasal dari mereka. Saya akan mulai dengan DogPiece. Tes pertama ... ahh. Sebenarnya tidak ada logika di sini. Ya, masing-masing bagian akan ditarik secara berbeda, jadi saya mungkin perlu DogDrawer, tapi sementara saya menyempurnakan permainan, saya hanya ingin menulis "D" di layar. Saya akan membumbui UI pada akhirnya.

Mari kita cari logika yang sebenarnya untuk diuji. Ada banyak rumah dan hotel ini, tetapi mereka tidak perlu tes. Uang, tidak. Kartu properti, tidak. Dan seterusnya. Bahkan papan tidak lain adalah mesin negara, itu tidak mengandung logika apa pun.

Anda akan segera menemukan ada tiga hal yang tersisa di tangan Anda. Kartu Peluang dan Dada Komunitas, sepasang dadu dan seperangkat aturan. Ini akan menjadi bagian penting untuk dirancang dan diuji.

Apakah Anda melihat itu datang ketika Anda menulis kata benda dan kata kerja?

Faktanya, ada contoh yang bagus dalam Pola dan Praktek Prinsip Agile Robert Martin di mana mereka mencoba menyempurnakan aplikasi Kartu Skor Bowling menggunakan TDD dan menemukan segala macam hal yang mereka pikir adalah kelas yang jelas tidak perlu diganggu.

Saya tidak pernah menemukan metode seperti itu bermanfaat bagi saya. Bahkan saya menemukan bahwa menggunakan mereka justru membingungkan saya lebih buruk. Lihat Pembuat Kopi Robert C. Martin , saya juga tidak berpikir dia menggunakan pendekatan semacam ini.

Satu hal yang langsung menggangguku adalah solusi yang diberikan orang tersebut pada artikel CRC yang Anda tautkan. Kolaborasi Pelanggan / Pesanan bukanlah sesuatu yang saya anggap berharga, tidak seperti yang tertulis. Tidak ada yang menarik dalam model tentang Pelanggan yang layak mendapatkan status kelas. Satu-satunya hal yang menarik tentang menjadi "pelanggan" adalah ada satu atau lebih pesanan yang terkait dengan Orang itu .

Model perguruan tinggi juga. Ada banyak hal yang dapat dilakukan, dan mungkin harus dibagikan antara Mahasiswa dan Profesor. Lebih jauh, apa yang terjadi ketika Anda memiliki seorang Profesor yang mengambil kelas, seperti yang sering kali diberikan secara gratis di kampus-kampus?

Saya kira itu mungkin praktik yang bermanfaat, satu elemen dalam toolkit desain. Saya tidak berpikir itu harus menjadi satu-satunya cara Anda mendekati desain setidaknya. Terus terang, saya menemukan pendekatan analisis kesamaan / variasi lebih berguna. Tampaknya bagi saya untuk memodelkan sangat erat apa yang kita lakukan dalam mengklasifikasikan abstraksi selama kehidupan sehari-hari.

Sunting: Cukup baca setengah dari blog kedua itu dan saya harus mengatakan bahwa saya cukup setuju dengannya. Saya harus membaca sisanya dan melihat apa yang ditawarkannya dalam hal belajar.

Pendapat saya adalah bahwa kelas harus ditambahkan (dan dihapus) saat Anda membuat kode untuk memisahkan masalah dan mengurangi ketergantungan. Menjadi fasih dalam pola desain mungkin merupakan taruhan yang baik untuk melihat kemungkinan refactoring dan penyederhanaan.

Kelas secara umum, menurut pengalaman saya, tidak masuk dalam kategori kata benda / kata kerja tetapi sebaliknya Anda akan berakhir dengan campuran kelas kata benda / kata kerja bersama dengan kelas pola yang berbeda (pabrik, lajang, pola strategi dll) dan kelas manajer lainnya yang membahas aspek aplikasi Anda.

Kuncinya adalah bahwa tujuan Anda harus dapat melihat kelas dan menyimpulkan apa yang dilakukannya dan memodifikasinya dengan hanya mengubah kelas itu. Semakin banyak kode untuk aspek aplikasi Anda tersebar di antara kelas, semakin sulit untuk mengikuti, mengelola, dan memperluasnya.