Tidak , suatu objek tidak harus mewakili suatu entitas.
Bahkan, saya berpendapat bahwa ketika Anda berhenti berpikir tentang objek sebagai entitas fisik adalah ketika Anda akhirnya mendapatkan manfaat yang dijanjikan OOP.
Ini bukan contoh terbaik, tetapi desain Pembuat Kopi mungkin di mana cahaya mulai menyala untuk saya.
Objek adalah tentang pesan. Mereka tentang tanggung jawab. Itu bukan tentang Mobil, Pengguna, atau Pesanan.
Saya tahu kita mengajar OO dengan cara ini, tetapi menjadi jelas setelah beberapa kali mencoba betapa frustrasinya itu untuk mencari tahu ke mana perginya ketika Anda mencoba melakukan MVC, MVVM atau MV apa pun. Entah model Anda menjadi kembung sangat konyol atau pengendali Anda melakukannya. Untuk navigasi, senang mengetahui bahwa apa pun yang menyentuh Kendaraan ada dalam file Vehicle.ext, tetapi ketika aplikasi Anda tentang Kendaraan, Anda pasti akan mendapatkan 3000 baris spageti dalam file itu.
Ketika Anda memiliki pesan baru untuk dikirim, Anda memiliki setidaknya satu objek baru, dan mungkin sepasang objek. Jadi, dalam pertanyaan Anda tentang seikat metode, saya berpendapat bahwa Anda berpotensi berbicara tentang seikat pesan. Dan masing-masing bisa menjadi objeknya sendiri, dengan tugasnya sendiri. Dan itu tidak masalah. Ini akan menjadi jelas ketika Anda memisahkan hal-hal mana yang benar-benar perlu disatukan. Dan Anda menyatukannya. Tetapi Anda tidak segera menjatuhkan setiap metode di laci yang samar-samar sesuai untuk kenyamanan jika Anda ingin menikmati OO.
Mari kita bicara tentang sekumpulan fungsi
Objek dapat berupa kumpulan metode dan masih menjadi OO, tetapi "aturan" saya cukup ketat.
Koleksinya harus memiliki satu tanggung jawab, dan tanggung jawab itu tidak boleh sebesar generik seperti "Melakukan barang untuk motor". Saya mungkin melakukan hal semacam itu sebagai fasad lapisan layanan, tetapi saya sangat sadar bahwa saya malas untuk alasan navigasi / penemuan, bukan karena saya mencoba menulis kode OO.
Semua metode harus pada lapisan abstraksi yang konsisten. Jika satu metode mengambil objek Motor dan yang lain mengembalikan Horsepower, itu mungkin terlalu jauh.
Objek harus bekerja pada "jenis" data yang sama. Objek ini melakukan hal-hal untuk motor (mulai / berhenti), yang ini melakukan hal-hal dengan panjang engkol, yang satu ini menangani urutan pengapian, yang ini mengambil bentuk html. Data ini dapat berupa bidang pada objek dan itu akan tampak kohesif.
Saya biasanya membangun objek semacam ini ketika saya melakukan transformasi, komposisi, atau hanya tidak ingin khawatir tentang mutabilitas.
Saya menemukan fokus pada tanggung jawab objek membawa saya ke arah kohesi. Harus ada suatu kohesi untuk menjadi objek, tetapi tidak perlu ada bidang atau perilaku yang terlalu banyak untuk menjadi objek. Jika saya sedang membangun sistem yang membutuhkan 5 metode motor itu, saya akan mulai dengan 5 objek berbeda yang melakukan hal-hal itu. Ketika saya menemukan kesamaan, saya akan mulai menggabungkan hal-hal bersama atau menggunakan benda-benda "pembantu" yang umum. Itu memindahkan saya ke masalah terbuka / tertutup - bagaimana saya bisa mengekstrak sedikit fungsionalitas ini sehingga saya tidak perlu memodifikasi file tertentu lagi tetapi masih menggunakannya di mana diperlukan?
Objek adalah tentang pesan
Bidang nyaris tidak berarti bagi suatu objek - mendapatkan dan mengatur register tidak mengubah dunia di luar program. Berkolaborasi dengan objek lain menyelesaikan pekerjaan. Namun, kekuatan OO adalah kita dapat membuat abstraksi sehingga kita tidak harus memikirkan semua detail individu sekaligus. Abstraksi yang bocor atau tidak masuk akal bermasalah, jadi kami berpikir secara mendalam (terlalu banyak, mungkin) tentang membuat objek yang cocok dengan model mental kita.
Pertanyaan kunci: Mengapa kedua benda ini perlu berbicara satu sama lain?
Pikirkan objek tersebut sebagai organ dalam diri seseorang - ia memiliki tujuan default dan hanya mengubah perilaku ketika menerima pesan tertentu yang ia pedulikan.
Bayangkan sebuah skenario di mana Anda berada di penyeberangan dan sebuah mobil melaju kencang. Sebagai objek otak, saya mendeteksi stresor. Saya memberi tahu hipotalamus untuk mengirim hormon pelepas kortikotropin. Kelenjar hipofisis mendapatkan pesan itu dan melepaskan hormon kortikotrofik adrenal. Kelenjar adrenal mendapatkan pesan itu dan membuat adrenalin. Ketika objek otot mendapatkan pesan adrenalin itu berkontraksi. Ketika hati menerima pesan yang sama, jantung berdetak lebih cepat. Ada seluruh rantai pemain yang terlibat dalam memulai perilaku kompleks berlari di seberang jalan dan itu adalah pesan yang penting. Objek otak tahu bagaimana membuat hipotalamus mengirimkan peringatan, tetapi tidak tahu rantai benda yang pada akhirnya akan membuat perilaku terjadi. Demikian juga hati tidak tahu dari mana adrenalin berasal,
Jadi, dalam contoh ( disederhanakan ) ini, objek kelenjar adrenal hanya perlu tahu cara mengambil ACTH dan membuat adrenalin. Tidak perlu bidang apa pun untuk melakukan itu, namun masih tampak seperti objek bagi saya.
Sekarang jika aplikasi kita dirancang hanya untuk berlari di seberang jalan, aku mungkin tidak membutuhkan kelenjar pituitari dan objek kelenjar adrenal. Atau saya hanya perlu objek kelenjar pituitari yang hanya melakukan sebagian kecil dari apa yang secara konseptual kita lihat sebagai "model kelenjar pituitari". Semua konsep ini ada sebagai entitas konseptual, tetapi merupakan perangkat lunak dan kita dapat membuat AdrenalineSender atau MuscleContractor atau apa pun dan tidak terlalu khawatir tentang "ketidaklengkapan" model kami.