Ini adalah topik umum untuk holivar. Misalnya:
Jangan gunakan OOP. Tidak pernah. Ini salah.Kutipan dari holivar
Ada banyak materi tentang topik ini, misalnya: www.youtube.com/watch?v=QM1iUe6IofM
Jika OOP masih tampak seperti ide yang bagus untuk Anda, selesaikan masalah sederhana.
Ada tiga objek: kucing, pemberi makan, dan manusia. Anda perlu menulis metode yang memungkinkan seseorang memberi makan kucing menggunakan feeder.
Pertanyaan: metode kelas manakah yang akan menjadi metode .feed ()?
Berikan jawaban yang masuk akal sesuai dengan hierarki kelas dan praktik terbaik OOP lainnya.
Sekarang bandingkan ini dengan implementasi fungsional: Anda memiliki fungsi feedCat () yang mengambil referensi ke kucing dan pengumpan sebagai argumen.
Bagaimana menjawab pertanyaan ini?
Pertama, mari kita lihat contoh dari fisika.
Kasus 1 (dari fisika): Hukum Ohm
Hukum Ohm: I = U / R, di mana I adalah arus, U adalah tegangan, R adalah resistansi.
Sangat mudah untuk melihat bahwa hukum Ohm, seperti rumus lain dari tiga variabel, dapat ditulis dalam tiga cara: I = U / R, R = U / I, U = IR. Bagaimana cara mengembangkan aturan yang memungkinkan Anda secara unik menentukan satu bentuk rekaman? Ini sangat sederhana: Anda perlu menuliskan kuantitas turunan di sisi kiri, mis. salah satu yang menjadi nilai tertentu, tergantung pada sisa kuantitas.
I = U / R "Kekuatan arus MENJADI sama dengan rasio tegangan pada ujung konduktor dengan resistansi konduktor" - benar.
U = IR "Tegangan di ujung konduktor MENJADI sama dengan resistansinya dikalikan dengan arus yang melalui konduktor" - tidak benar.
R = U / I "Resistansi konduktor MENJADI sama dengan rasio tegangan di ujung ke arus" - tidak benar.
Anda lihat - setelah kami sepakat bahwa nilai turunan ada di sebelah kiri, hanya ada satu opsi yang tersisa.
Kami akan melakukan hal yang sama di OOP. Mari kita sepakati bahwa metode ini milik orang yang bertindak:
Who_Acts . Method (Action_Object);
Kasus 2: Siapa yang membawa Ismael?
Karena itu, ketika menjawab pertanyaan "Siapa yang membawa Ismael?" dari sudut pandang pemrograman berorientasi objek, dan dari sudut pandang "siapa yang mempengaruhi?", jawaban yang benar adalah Suvorov Take Fortress (Izmail, Turks): boolean. Semua opsi lainnya, seperti: Turks.Pro *** tKrepost (Izmail, Suvorov), Izmail. Perubahan Pemilik (Turks, Suvorov), Benteng Abstrak, Ditangkap (Ismail, Suvorov, Turki), dll. - semua opsi ini tidak benar.
Kasus 3: Manusia, Pengumpan dan Kucing
"Beri makan kucing!" dari situs corchaosis.ru
Seorang pria menuangkan makanan ke dalam palung. Metode ini:
.(,). Saat metode dijalankan, jumlah makanan berkurang di variabel global Paket Makanan, dan muncul di variabel global Pengumpan.
Bagaimana dengan kucingnya? Dan kucing itu ada SEBELUM memanggil metode PourFoodCat, sebagai syarat untuk memanggilnya. Jika kucing ada di pedesaan, maka metode Pour Food tidak akan dipanggil ke kucing.
Kasus 4: DOOM Player, Shotgun, dan Monster
Katakanlah pertanyaan tentang memukul monster tidak memiliki gradasi: memukul atau tidak memukul.
Implementasi yang benar. Semuanya dimulai dengan metode Player:
(, _1 ).(_1)
Di dalam implementasi metode Shot, kita melihat bahwa senjata pemain saat ini adalah shotgun.
Oleh karena itu, kami memanggil metode objek bersarang:
_1.[_1.__].(_1)
Player_1 Senjatanya adalah kelas TWeapon.
Dalam hal ini, metode kelas TShotgun dipanggil, yang merupakan anak dari TWeapon.
Jadi, kami memiliki:
.(_1)
Shotgun, saat melakukan tindakan ini, mengubah keadaan internal: untuk Shotgun, ini adalah jumlah selongsong peluru (dan untuk jenis senjata lain, misalnya, mungkin ada suhu). Selain itu, kami menentukan kekuatan kerusakan - misalnya, senapan menembakkan 2 peluru sekaligus, tetapi juga dapat menembakkan satu peluru jika hanya ada satu putaran tersisa dalam muatan.
Jika kita menembakkan peluncur roket, objek baru akan muncul - roket. Dengan metode Tick-nya sendiri, yang memproses tindakan dalam satu tick waktu game (waktu game berubah, biasanya dalam ticks). Tapi kami menembakkan senjata yang bisa menyerang tanpa penundaan, jadi kami tahu jumlah peluru yang ditembakkan (1 atau 2), kami tahu jaraknya (membandingkan Player.Posisi dan Monster_1.Posisi), dan di dalam metode kelas Shotgun, kami menghitung kerusakan.
Dan akhirnya
_1.(_:Float). Sekarang, seperti sebelumnya, shotgun mengubah status internalnya (jumlah kartrid), sekarang Monster_1 mengubah _1.skenario kondisi dan perilaku internal (terutama jika Kesehatan menjadi kurang dari nol).
Jadi, kami melihat bahwa berkat OOP, kami dapat dengan mudah menambahkan senjata baru: cukup gambarkan sebagai kelas anak dari TWeapon, tentukan Shot dan letakkan di peta. Kelas Player sudah tahu bagaimana memilih dan menambahkan objek TWeapon ke playsetnya. Semua. Meski tidak, tidak semuanya. Jika senjata akan memberikan bunga kepada monster, memaksa mereka untuk jatuh cinta dengan pemain, maka monster juga harus diberi metode
:boolean, serta serangkaian metode lain - tergantung pada tingkat elaborasi, dalam hal ini Anda mungkin memerlukan sejumlah objek OOP baru dan metode mereka.
Kasus 5: Penanganan adalah fungsi atau metode
Tidak hanya jawaban atas pertanyaan ini, tetapi antarmuka interaksinya sendiri, tentu saja, bergantung pada objek yang disentuh.
_::Apakah sebuah fungsi.
Handpick :: laptop adalah metode objek laptop. Anda harus menggunakan antarmuka untuk memanggil metode laptop "KeyDown, KeyUp, KeyPressed" meneruskan data yang benar ke metode ini: tombol mana yang ditekan, pada titik waktu apa, dll.
_::Apakah metode objek Anda. Anda membutuhkan objek "diri" yang perubahan statusnya akan menggambarkan luka bakar tangan dengan benar. Api tidak akan mengubah keadaan.
Saya pikir Anda sendiri dapat melanjutkan daftar antarmuka objek yang dapat Anda sentuh dengan tangan Anda untuk mendapatkan latihan menggunakan pemrograman berorientasi objek.