Kapan kita benar-benar menggunakan pemrograman berorientasi objek? [Tutup]

Saya menulis sebuah program dengan Python, yang pada dasarnya memanipulasi string, dan saya bertanya-tanya apakah saya harus melakukannya dengan menggunakan prinsip OOP atau tidak. Klien mengatakan kepada saya bahwa dia tidak peduli dengan kode itu, dia hanya ingin hal itu dilakukan .

Saya tahu bahwa kode berorientasi objek bukan dengan pembersih definisi, dan sebaliknya kode non-OO bukan oleh definisi jelek. Pertanyaan yang saya ajukan mungkin lebih atau kurang didasarkan pada opini tetapi mungkin ada beberapa aturan yang tidak saya sadari.

Beberapa info lebih lanjut tentang apa yang harus dilakukan:

• parsing .csvfile dan proses data berdasarkan file konfigurasi (kolom mungkin berbeda - seperti jumlah kolom atau data yang dipegangnya)
• menggunakan data yang diproses di atas untuk membuat data yang diformat khusus (atau beberapa file berdasarkan beberapa nilai di atas)
• menggunakan data yang diformat terakhir untuk membuat file XML.
• pisahkan file XML dalam beberapa XMLs berdasarkan konten mereka
• aplikasi harus berbasis CLI
• tentu saja ada hal-hal lain seperti: mencatat beberapa peristiwa, menguraikan argumen CLI, dan sebagainya.

Sekarang, ini sama sekali bukan aplikasi besar / sulit, dan itu juga hampir selesai tetapi selama seluruh proses pengembangan saya terus bertanya pada diri sendiri apakah ini harus dilakukan dengan menggunakan OOP atau tidak.

Jadi, pertanyaan saya adalah: bagaimana kalian, tahu / memutuskan kapan harus menggunakan OOP dalam suatu aplikasi?

Python adalah bahasa multi-paradigma yang berarti Anda dapat memilih paradigma yang paling sesuai untuk tugas tersebut. Beberapa bahasa seperti Java adalah paradigma tunggal OO yang berarti Anda akan sakit kepala jika Anda mencoba menggunakan paradigma lain. Poster yang mengatakan "selalu gunakan OO" mungkin berasal dari latar belakang dalam bahasa seperti itu. Tapi untungnya Anda punya pilihan!

Saya perhatikan program Anda adalah aplikasi CLI yang membaca beberapa input (file csv dan config) dan menghasilkan beberapa output (file xml), tetapi tidak interaktif dan karenanya tidak memiliki GUI atau API stateful. Program semacam itu secara alami dinyatakan sebagai fungsi dari input ke output, yang mendelegasikan ke fungsi lain untuk subtugas.

OO di sisi lain adalah tentang merangkum keadaan yang bisa berubah dan oleh karena itu lebih cocok untuk aplikasi interaktif, GUI, dan keadaan pengungkapan API yang dapat diungkapkan. Bukan kebetulan bahwa OO dikembangkan secara paralel dengan GUI pertama.

OO memiliki keunggulan lain dalam polimorfisme yang memungkinkan Anda menggunakan arsitektur yang lebih longgar, di mana implementasi berbeda dari antarmuka yang sama dapat dengan mudah diganti. Dikombinasikan dengan injeksi dependensi ini dapat memungkinkan pemuatan dependensi berbasis konfigurasi dan hal-hal keren lainnya. Ini sebagian besar cocok untuk aplikasi yang sangat besar. Untuk program sebesar apa yang Anda gambarkan, itu akan jauh lebih mahal tanpa manfaat yang jelas.

Terlepas dari fungsi yang sebenarnya membaca dan menulis file, sebagian besar logika Anda dapat ditulis sebagai fungsi bebas efek samping yang mengambil beberapa input dan mengembalikan beberapa output lainnya. Ini sangat mudah untuk diuji, jauh lebih sederhana daripada menguji unit OO di mana Anda perlu mengejek dependensi dan yang lainnya.

Intinya: Saya menyarankan banyak fungsi yang dipecah menjadi modul untuk organisasi, tetapi tidak ada objek.

Pertimbangkan tombol pada GUI. Ini memiliki status (ukuran, warna, posisi, label dll). Hal-hal dapat terjadi padanya (diklik, perlu digambar ulang dll). Dalam situasi seperti itu, memodelkannya sebagai objek masuk akal. Sebagai objek, ia dapat berisi statusnya, serangkaian tindakan yang dapat dilakukan padanya (metode) dan dapat memberi tahu bagian lain dari aplikasi bahwa sesuatu telah terjadi padanya dengan menembakkan peristiwa.

OOP adalah alat yang hebat untuk menangani GUI, dan situasi lain di mana bagian dari sistem memiliki kondisi volatil.

Situasi lain, seperti yang Anda gambarkan, di mana data dibaca dari sumber, diproses dan ditulis ke tujuan ditangani dengan baik oleh pendekatan yang berbeda: pemrograman deklaratif (atau fungsi). Kode deklaratif untuk pemrosesan data cenderung lebih mudah dibaca dan lebih pendek daripada solusi OOP.

Seperti halnya palu dan gergaji, keduanya merupakan alat yang sangat kuat bila digunakan dengan benar, demikian pula teknik pemrograman berorientasi objek dan deklaratif. Anda mungkin bisa memalu paku ke sepotong kayu dengan gagang gergaji. Demikian juga, Anda dapat mematahkan kayu menjadi dua dengan palu. Demikian juga, Anda dapat membuat GUI hanya dengan fungsi dan memproses data dengan objek. Ketika alat digunakan dengan benar, hasilnya lebih bersih dan sederhana.

Aturan umum yang saya gunakan adalah bahwa jika saya memiliki banyak status, atau membutuhkan interaksi pengguna, saya menggunakan objek; kalau tidak saya menggunakan fungsi (murni dan lebih tinggi, jika memungkinkan).

Pemrograman Berorientasi Objek menambahkan empat alat baru ke gudang senjata Anda:

1. Enkapsulasi
2. Abstraksi
3. Warisan
4. Polimorfisme

Anda akan menggunakan OOP dalam aplikasi Anda ketika telah tumbuh cukup besar dan cukup kompleks untuk mendapat manfaat dari alat ini.

Pertanyaan ini sepertinya agak membingungkan bagi saya. Jika Anda menulisnya dengan Python, Anda pasti akan menggunakan objek. Ketika Anda membuka file, itu mengembalikan objek. Ketika Anda menghasilkan hasil, itu mengembalikan Objek iterator. Setiap fungsi yang Anda buat adalah objek. Mempertanyakan nilai OO dalam aplikasi Python tampaknya aneh untuk sedikitnya.

Berdasarkan komentar di sini, ya, Python mendukung paradigma fungsional tetapi terutama berbasis objek. Bahasa itu sendiri dan built-in lib berorientasi pada objek. Ya itu mendukung lambda (seperti halnya Java dan sejumlah bahasa lainnya yang biasanya digambarkan sebagai OO) tetapi sengaja disederhanakan dibandingkan dengan bahasa fungsional yang sebenarnya.

Mungkin perbedaan seputar desain OO dan desain fungsional ini menjadi usang. Jika saya membuat mengambil fungsi polimorfik pada OO objek * yang dirancang dan lulus pointer ke fungsi pada objek sebagai parameter ke fungsi fungsional *, apakah itu OO atau fungsional? Saya pikir itu baik dan juga pendekatan yang sangat efektif untuk menyelesaikan masalah.

Saya pikir pertanyaan sebenarnya adalah 'kapan Anda harus mulai mendesain kelas Anda sendiri versus hanya membuat modul dengan fungsi?' Saya pikir jawaban yang tepat untuk itu adalah: ketika itu membantu menyederhanakan solusinya. Saya akan memberikan jawaban dasar yang sama untuk bahasa berorientasi objek.

* redundansi disengaja: Saya tidak ingin dituduh di sini dengan menganggap objek OO atau fungsi berfungsi.

Salah satu hal terbesar tentang pemrograman berorientasi objek adalah bahwa alih-alih berpikir tentang aliran program, Anda mulai berpikir tentang keadaan.

Banyak kali saya melihat objek, saya melihat metode tetapi apa yang saya juga lihat adalah bahwa pemikiran mengemudi di balik kode adalah aliran bukannya negara.

Dan begitu Anda beralasan tentang keadaan, mudah untuk membuat kode OOP yang baik karena begitu kode Anda menjadi terlalu rumit, Anda akan melihat bahwa Anda tidak dapat lagi beralasan tentang keadaan Anda dan tahu Anda perlu melakukan refactor.

Pertimbangkan contoh Anda: Anda ingin mengurai file csv. Dari mana asalnya: file pada disk. Anda memuatnya dan memasukkannya ke dalam memori dan menguraikannya. Sekarang klien Anda datang: hei saya juga ingin mem-parsing file dari web. Jadi Anda senang karena Anda membuat antarmuka yang bagus untuk memuat file Anda dan hanya perlu membuat kode yang mengambilnya dari web dan sisa program Anda tetap sama persis.

Dan yang menyenangkan adalah: Anda dapat menguji untuk itu.

Dalam istilah awam:

• Anda dapat menggunakan OOP atau non-OOP dalam proyek apa pun yang Anda inginkan.
• OOP bukan obat mujarab tetapi membantu mengelola kompleksitas.
• Ini melampaui modularitas, ini tentang kompartementalisasi. Pikirkan berbagai kompartemen yang dimiliki kapal untuk mempertahankan daya apung jika lambung rusak.
• OOP adalah cara mengelola dependensi sehingga bug dapat lebih mudah dilacak karena hanya ada seperangkat cara yang ditentukan oleh berbagai komponen program untuk berkomunikasi yang lain.
• Dalam sebuah program ada banyak hal yang berfungsi: variabel, konstanta, metode, file, parameter, fungsi, modul, dll. Mereka dapat berinteraksi satu sama lain dengan cara yang kadang-kadang dapat diprediksi. OOP adalah seperangkat prinsip yang mengurangi jumlah cara hal-hal dapat berinteraksi satu sama lain. Anda tidak dipaksa menggunakan OOP untuk melakukan itu, tetapi itu membantu.

Yang mengatakan, ada faktor-faktor lain yang perlu dipertimbangkan:

• Apakah programmer Anda mahir dalam OOP / OOD?
• Apakah programmer Anda mahir dalam bahasa OOP?
• Apakah Anda pikir perangkat lunak akan tumbuh kompleks dari waktu ke waktu?
• Apakah Anda berencana untuk menskalakan atau menggunakan kembali kode di masa mendatang?
• Apakah Anda pikir "desain" Anda bisa menjadi aset? yaitu apakah Anda dapat memanfaatkannya untuk tumbuh atau sebagai dasar untuk proyek masa depan?

Jangan salah: Anda dapat mencapai semua itu tanpa menggunakan OOP tetapi dengan OOP akan lebih mudah.

Tapi...

Jika tim Anda tidak mahir dalam OOP / OOD dan tidak memiliki keahlian di bidang itu, gunakan sumber daya yang Anda miliki.

Jadi, pertanyaan saya adalah: bagaimana kalian, tahu / memutuskan kapan harus menggunakan OOP dalam suatu aplikasi?

Selalu gunakan itu. Setelah Anda terbiasa menggunakannya, Anda akan menggunakannya untuk semuanya. Ini adalah cara yang bagus untuk memastikan abstraksi yang baik antara kemampuan dan penggunaannya, yang merupakan manfaat signifikan bagi pemeliharaan. Kami menggunakannya, misalnya, untuk

• objek struktur data kecil karena ini sering polimorfik, misalnya dan struktur data menengah setelah parsing sesuatu sering memiliki banyak entitas kecil, yang memiliki perilaku umum namun juga khusus. Ini adalah kasus penggunaan yang bagus untuk kelas dasar atau antarmuka umum, dengan implementasi & perilaku khusus, yaitu hierarki kelas (polimorfisme).

• logging, sebagai contoh, karena memudahkan untuk mengganti logger yang berbeda

• potongan besar struktur program, karena Anda menyulap beberapa yang bersamaan, dan mungkin mengambil keuntungan dari prosesor multi cpu. Misalnya, server web dapat dengan mudah menggunakan beberapa penangan permintaan bersamaan, karena objek.

Itu membuat refactoring dan penggunaan kembali lebih mudah, seperti yang saya sebutkan, mendorong abstraksi yang baik, yang semuanya memudahkan perawatan. OOP harus dianut dan digunakan sepanjang waktu. Pemrograman OOP yang baik menghindari metode statis dan / atau data statis, dan menggunakan objek untuk semuanya.

Pemrograman Berorientasi Objek menyediakan alat untuk membuat kerangka kerja. Alat-alat ini adalah Enkapsulasi, Abstraksi, Warisan dan Polimorfisme. Ide-ide ini akan membantu Anda membagi program Anda menjadi dua bagian.

Cara - Ini adalah bagian kerangka kerja kode Anda, tempat Anda membuat semacam abstraksi, memutuskan bagaimana blok Anda bekerja secara umum dan bagaimana interaksi dengan blok lain.

Apa yang harus - Bagian ini adalah tempat balok melakukan pekerjaan yang sebenarnya. Di sini kelas diturunkan dari kelas dasar buat di "Cara ke bagian".

Orang bisa mendapat manfaat besar dari OOPS

1. jika Anda dapat menggunakan kembali kerangka kerja yang ada dan hanya perlu mengimplementasikan detail spesifik di bagian "apa yang harus dilakukan".
2. Fungsi yang sedang dilaksanakan untuk proyek saat ini adalah generik / umum digunakan dan proyek lain / proyek masa depan dapat memperoleh manfaat dari kerangka kerja yang dibuat saat pengembangan proyek saat ini.
3. Memecah proyek-proyek besar menjadi pola umum untuk memecahkan masalah besar.
4. Gunakan OOPS bahkan untuk proyek kecil untuk terbiasa menggunakannya dan siap ketika 1-3 jenis masalah muncul