Mengapa baik membagi program menjadi beberapa kelas? [Tutup]

Saya masih seorang siswa di sekolah menengah (memasuki kelas 10), dan saya belum mengambil kursus komputer yang sebenarnya di sekolah. Semua yang saya lakukan sejauh ini adalah melalui buku. Buku-buku itu telah mengajarkan saya konsep-konsep seperti pewarisan, tetapi bagaimana membagi program menjadi beberapa kelas membantu? Buku-buku tidak pernah memberi tahu saya.

Saya menanyakan ini terutama karena proyek baru-baru ini. Ini adalah video game arcade, semacam game Flash seperti yang dikatakan beberapa orang (walaupun saya tidak tahu apa itu game Flash ). Masalahnya, itu hanya satu kelas. Ini berfungsi dengan baik (sedikit lag sesekali) dengan hanya satu kelas. Jadi, saya hanya bertanya bagaimana membaginya menjadi beberapa kelas akan membantu.

Proyek ini di Jawa dan saya satu-satunya orang yang mengerjakannya, sebagai catatan.

Jawaban paling sederhana adalah bahwa jika Anda meletakkan semuanya ke dalam satu kelas, Anda harus khawatir tentang semuanya sekaligus ketika Anda sedang menulis kode baru. Ini mungkin bekerja untuk proyek-proyek kecil, tetapi untuk aplikasi besar (kita berbicara ratusan ribu baris), ini dengan cepat menjadi hampir mustahil.

Untuk mengatasi masalah ini, Anda memecah fungsionalitas ke dalam kelas mereka sendiri dan merangkum semua logika. Kemudian ketika Anda ingin bekerja di kelas, Anda tidak perlu memikirkan apa lagi yang terjadi dalam kode. Anda bisa fokus pada potongan kecil kode itu. Ini sangat berharga untuk bekerja secara efisien, namun sulit untuk menghargai tanpa mengerjakan aplikasi yang besar.

Tentu saja ada manfaat lain yang tak terhitung jumlahnya untuk memecah kode Anda menjadi potongan-potongan kecil: kode lebih mudah dikelola, lebih dapat diuji, lebih dapat digunakan kembali, dll, tetapi bagi saya manfaat terbesar adalah membuat program besar dapat dikelola dengan mengurangi jumlah kode yang Anda perlu dipikirkan pada satu waktu.

Yah, respons paling sederhana mungkin adalah "Ini membantu mengatur berbagai hal." Jika tidak ada yang lain, Anda dapat membandingkannya dengan bagian-bagian dalam buku catatan - itu lebih sederhana jika Anda memiliki "semua hal yang berkaitan dengan UI" di sini dan "semua hal yang berkaitan dengan gameplay" di sana.

Jawaban yang lebih canggih adalah bahwa membagi pekerjaan tidak hanya nyaman, tetapi sangat penting untuk mengelola kompleksitas (dan "mengelola kompleksitas" cukup banyak nama permainan ketika datang ke pemrograman). Kelas, atau jenis modul lainnya, memungkinkan Anda untuk "memisahkan masalah." Anda tidak hanya tahu di mana mencari "hal-hal yang terkait dengan UI" tetapi Anda dapat yakin bahwa jika Anda ingin membuat perubahan ke UI, Anda bisa membuatnya di satu tempat, dan Anda tidak perlu khawatir "sekarang, apakah itu satu - satunya tempat saya mengatur font saya ke Comic Sans?". Dan Anda dapat membuat perubahan dan tahu bahwa efek dari perubahan itu hanya untuk ruang lingkup apa pun (kecil) yang sesuai. Jika semuanya dalam satu kelas atau modul, pada dasarnya semuanya adalah global,

Dalam kasus spesifik kelas sebagai jenis modul perangkat lunak, ada juga banyak perilaku yang dikaitkan dengan kelas, dan sebagian besar pengembang dalam paradigma berorientasi objek merasa sangat membantu untuk memiliki nama yang bermakna yang terkait dengan kelas yang terkait dengan kelompok berfungsi bersama. Jadi Anda mungkin tidak akan benar-benar memiliki UIkelas, Anda mungkin memiliki Buttonkelas. Ada banyak pengetahuan dan teknik yang terkait dengan desain kelas berorientasi objek dan ini adalah cara paling umum untuk mengatur sistem besar dalam pemrograman arus utama.

Ini pertanyaan yang bagus! Sederhana dan ditanyakan dengan baik. Yah ... jawabannya tidak begitu mudah dimengerti bagi siswa yang sedang mempelajari ilmu komputer dan mungkin tidak tahu dalam OO yang mendalam dan mungkin tidak memiliki pengalaman bekerja.

Jadi, saya bisa menjawab dengan menggambarkan sebuah skenario dan membuat Anda membayangkan bagaimana perangkat lunak multi-kelas lebih baik daripada perangkat lunak monolitik (dibuat oleh satu kelas saja):

• Keterbacaan : Jauh lebih sulit untuk menelusuri dan menulis kode di dalam file dengan 10.000 baris daripada beberapa file kecil dan terorganisir.
• Kegunaan ulang : Jika Anda menulis satu kelas, Anda bisa tergelincir dalam duplikasi kode . Ini berarti lebih banyak baris kode dan mungkin lebih banyak bug (!)
• Testabilitas : Bagaimana dengan menguji fungsionalitas tunggal? Jika Anda mengisolasi satu fungsi logika dalam satu kelas, hidup Anda akan lebih mudah.
• Pemeliharaan kode : Anda dapat memperbaiki bug atau meningkatkan fungsionalitas dengan kelas banyak dalam satu tempat: Kelas kecil yang menyenangkan.
• Struktur proyek : oooooh dapat Anda bayangkan betapa jeleknya proyek dengan hanya satu file sumber akan muncul?

Ada banyak jawaban bagus di sini, dan saya pasti setuju dengan mereka, tetapi saya merasa ada sesuatu yang lebih layak disebut.

Saat ini, seperti yang Anda katakan, Anda bekerja sendiri dalam proyek Anda. Namun, di masa mendatang, ada saatnya Anda perlu bekerja dalam pengaturan tim. Selama masa-masa itu, Anda akan membagi pekerjaan (mungkin proyeknya akan cukup besar). Akibatnya ada beberapa (saya kira benar-benar dua utama ) pilihan yang berbeda. Anda dapat memiliki banyak salinan dari satu file, dan bekerja pada "bagian" file yang terpisah dan kemudian "menggabungkan" dengan copy dan paste kemudian dan kemudian memodifikasi sehingga bagian Anda dapat bekerja bersama, atau Anda dapat membagi "potongan" itu cukup dengan mudah ke dalam kelas yang berbeda dan diskusikan bagaimana Anda akan menulis kelas-kelas itu, dan gunakan pengetahuan itu untuk melanjutkan.

Masih perlu bekerja untuk mengintegrasikan semua bagian yang terpisah bersama-sama, tetapi itu akan jauh lebih mudah untuk dipelihara. Karena file x berisi kode y dan itulah kode yang Anda tahu perlu Anda modifikasi. Ini masuk ke dalam hal organisasi yang sebagian besar jawaban lain bicarakan.

Memegang program di kepala seseorang. Tautan dari Giorgio

Akibatnya apa yang telah Anda lakukan adalah pemrograman prosedural yang diciptakan kembali. Pikiran Anda sangat mungkin untuk menulis perangkat lunak seperti itu dan kompiler mungkin tidak akan peduli. Selama bertahun-tahun inilah yang dilakukan sampai komputer menjadi lebih cepat dan alat menjadi lebih baik.

Yang dikatakan jika Anda memecah kode Anda menjadi unit logis yang berbeda (Kelas, modul dll) adalah bahwa Anda dapat memiliki banyak potongan kode yang mudah dimengerti. itu bisa dipertahankan nanti. Banyak modul saya kurang dari 20 baris kode. Saya tahu bahwa semua kode pada subjek tertentu ada di tempat tertentu. Ini juga berarti bahwa jika seseorang bergabung dengan proyek tersebut, mereka akan memiliki waktu yang jauh lebih mudah untuk menemukan sesuatu.

Seperti yang dikatakan Gerald Sussman, program kita harus ditulis terlebih dahulu sehingga orang dapat membacanya dan yang kedua agar komputer dapat menjalankannya. (Dan jika Anda belum membaca "Struktur dan Interpretasi Program Komputer, Anda harus)

Satu menggunakan beberapa kelas karena ketika Anda masuk ke hal-hal yang lebih besar Anda akan menemukan tidak ada cara Anda bisa melacak semuanya ketika itu adalah tumpukan besar kode.

Anda hanya perlu membagi dan menaklukkan untuk menanganinya.

Pemrograman berorientasi objek adalah satu-satunya ide terbaik yang pernah saya lihat dalam pemrograman. Tapi itu bukan hal terbaik dalam semua kasus, Anda perlu sedikit pengalaman pemrograman untuk memahami maksudnya, dan banyak orang yang mengaku melakukan OOP ketika tidak.

Jika Anda dapat mencari "pemrograman terstruktur" Anda mungkin akan menemukan sesuatu yang lebih bermanfaat segera. (Pastikan Anda membaca tentang pemrograman terstruktur lama . Istilah lama sering mendapatkan arti baru, lebih bagus, dan Anda belum memerlukan sesuatu yang mewah.) Ini adalah konsep yang agak sederhana tentang memecah program Anda menjadi subrutin, yang jauh lebih mudah daripada memecahnya menjadi benda-benda. Idenya adalah program utama Anda adalah rutin singkat yang memanggil subrutin ("metode" di Jawa) untuk melakukan pekerjaan itu. Setiap subrutin hanya tahu apa yang diceritakan oleh parameternya. (Salah satu parameter itu mungkin nama file, jadi Anda bisa sedikit curang.) Jadi, melihat judul subrutin / metode memberi Anda gambaran singkat tentang apa yang dilakukannya, hampir sekilas.

Kemudian semua subrutin dipecah sama hingga beberapa baris kode tanpa panggilan metode apa pun akan melakukan pekerjaan. Program utama yang memanggil beberapa metode, yang masing-masing memanggil beberapa metode, yang masing-masing .... Turun ke metode sederhana kecil yang melakukan pekerjaan. Dengan cara ini, Anda dapat melihat bagian mana pun dari program yang sangat besar (atau program kecil) dan dengan cepat memahami apa yang dilakukannya.

Java dirancang khusus untuk orang yang menulis kode Berorientasi Objek. Tetapi bahkan program OO yang paling intens menggunakan beberapa pemrograman terstruktur, dan Anda selalu dapat menumbangkan bahasa apa pun. (Saya melakukan OO di dataran C.) Jadi Anda dapat melakukan SP, atau apa pun, di Jawa. Lupakan kelas dan fokus pada metode besar yang dapat dipecah menjadi yang kecil, yang dapat dikelola. Saya harus menambahkan bahwa SP banyak membantu dengan membiarkan Anda menggunakan kembali kode Anda, dan juga dengan prinsip KERING (google itu, tetapi itu berarti "Jangan Ulangi Diri Sendiri").

Semoga saya sudah menjelaskan mengapa dan bagaimana membagi kode Anda menjadi beberapa bagian tanpa membawa "kelas". Mereka adalah ide bagus dan hanya cocok untuk game dan bahasa Jawa yang bagus untuk OOP. Tetapi lebih baik untuk mengetahui mengapa Anda melakukan apa yang Anda lakukan. Biarkan OOP sendiri sampai mulai masuk akal bagi Anda.

Salah satu manfaatnya adalah usability. Suatu program pada dasarnya adalah banyak instruksi yang dikelompokkan bersama. Anda akan menemukan bahwa beberapa instruksi tersebut juga cocok untuk program lain.

Katakanlah Anda membuat game lompat. Kemudian ketika Anda memutuskan untuk membuat permainan meriam, Anda menemukan bahwa perhitungan fisika yang Anda gunakan dalam permainan melompat berguna di sini.

Jadi, alih-alih menulisnya lagi, atau lebih buruk menyalin dan menempelkannya ke program baru, Anda membuatnya menjadi sebuah kelas. Jadi lain kali Anda membuat game lain di mana mekanik game membutuhkan fisika, Anda bisa menggunakannya kembali. Tentu saja ini terlalu disederhanakan, tapi saya harap masuk akal

Pertama-tama, perhatikan bahwa saya seorang C ++ dan Python, bukan Java, jadi beberapa di antaranya mungkin tidak berlaku sepenuhnya. Harap perbaiki saya jika saya membuat beberapa asumsi yang salah tentang cara kerja kelas di Java.

Kelas terutama berguna ketika mereka dipakai. Kelas yang tidak ada instance dibuat benar-benar hanya namespace yang dimuliakan. Jika Anda menggunakan semua kelas Anda dengan cara ini, maka tentu saja, manfaat memindahkan sesuatu dari namespace ke namespace mungkin tampak tidak signifikan - paling banyak, Anda akan menang dengan memiliki beberapa data pribadi di masing-masing dan dengan demikian merangkum hal-hal sedikit.

Namun, ini bukan tempat kelas bersinar. Pertimbangkan Stringkelasnya: Anda dapat memiliki semua fitur yang sama menggunakan chararray dan beberapa fungsi statis. Pada titik ini, fungsi memberi Anda sedikit keamanan ekstra dan gula sintaksis. Anda bisa menulis string.length()alih-alih length(char_array); itu bukan masalah besar, tetapi banyak orang masih menyukainya. Selain itu, Anda tahu bahwa jika seseorang memberi Anda String, itu dibuat dengan Stringkonstruktor dan itu harus bekerja dengan lengthfungsi - jika versi array tidak dapat menangani beberapa karakter maka tidak ada cara untuk mencegah Anda meletakkannya di sana .

Tapi tetap saja bukan itu. Poin kuncinya adalah bahwa kelas menggabungkan data dan fungsi yang beroperasi di dalamnya dan abstrak keduanya. Ketika Anda memiliki metode, void f(Builder b)Anda tahu Anda akan memperolehnya Builder, dan Anda dapat mengharapkannya akan mendukung perilaku tertentu. Namun, Anda tidak tahu apa-apa tentang data atau fungsi yang dieksekusi - pada kenyataannya, definisi untuk keduanya mungkin belum ditulis saat Anda menulis dan mengkompilasi f.

Poin pertama yang harus dipahami adalah kelas-kelas membuatnya nyaman untuk menyampaikan data sambil memastikan tidak rusak. Poin kedua adalah bahwa apa yang dimiliki data dan fungsi (implementasi) suatu objek adalah sesuatu tentang objek tersebut, bukan sesuatu yang bisa Anda ketahui dari tipenya.

Seluruh ide didasarkan pada aturan umum bernama divide and conquer .
Paradigma ini dapat digunakan hampir di semua tempat; Anda membagi masalah menjadi masalah yang lebih kecil dan kemudian Anda memecahkan masalah kecil, sederhana dan terkenal ini.
Membagi program Anda ke dalam kelas adalah salah satu jenis divisi yang mulai menjadi umum dalam dekade terakhir. Dalam paradigma pemrograman ini kami memodelkan masalah kami dengan beberapa objek dan mencoba menyelesaikan masalah dengan mengirim pesan di antara objek-objek ini.
Beberapa orang mungkin mengatakan bahwa pendekatan ini lebih mudah untuk dipahami, diperluas, dan didebug.
Meskipun beberapa orang tidak setuju :)

Ini bukan tentang memecah program menjadi beberapa kelas tetapi tentang bagaimana Anda memodelkan aplikasi Anda, yaitu bagaimana Anda memvisualisasikan bagian dari aplikasi Anda. Memisahkan hal-hal hanyalah mekanisme yang kita gunakan untuk memahami hal-hal rumit dengan lebih baik. Tidak hanya dengan pemrograman. Bayangkan papan sirkuit dengan banyak kabel terjalin satu sama lain, membentuk struktur kompleks dengan masing-masing kawat yang menghubungkan suatu tempat (kode spageti). Anda harus mengikuti setiap kabel sampai tuntas untuk mengetahui koneksi. Sebaliknya bayangkan kabel yang dikelompokkan dan diberi kode warna sesuai fungsinya. Menjadi jauh lebih mudah untuk memperbaiki keadaan.

Gagasannya adalah Anda tidak memulai dengan program yang panjang dan kemudian membaginya menjadi beberapa kelas. Tetapi Anda memodelkan aplikasi Anda dalam hal objek / kelas terlebih dahulu dan kemudian menghubungkannya untuk membangun aplikasi.