Kode Prosedural vs. kode OOP

Saya telah menyelesaikan sebuah proyek di PHP dengan 13.000+ baris dalam Gaya Prosedural [karena saya sangat terbiasa dengan itu, meskipun saya tahu OOP], dan proyek ini berjalan dengan sempurna.

Tetapi haruskah saya mengubahnya menjadi OOP? [ Karena dunia sibuk dengan OOP ]

Kode saya tidak memerlukan fitur OOP [enkapsulasi, pewarisan pada dasarnya ...]!

Jadi apa yang harus aku lakukan?

Dan bantuan apa yang akan saya dapatkan jika saya mengubahnya menjadi OOP?

Kode saya tidak memerlukan fitur OOP

Anda telah menjawab pertanyaan Anda sendiri - jika Anda tidak memerlukan OOP dalam kasus ini dan proyek Anda berfungsi maka jangan mengubahnya.

Namun, Anda harus melihat menggunakan OOP untuk proyek Anda berikutnya - tetapi hanya jika itu sesuai.

Pada dasarnya tidak ada yang salah dengan pemrograman prosedural - selama itu digunakan di tempat yang tepat.

Tidak dan bukan hanya karena Anda tidak membutuhkan OOP.

Jika program Anda sudah selesai dan bekerja dengan memuaskan maka lebih dari 90% dari waktu itu adalah buang-buang waktu untuk menulis ulang kode yang sudah jadi untuk alasan apa pun.

OOP tidak semua kuat ada banyak tempat di mana OOP tidak boleh digunakan jadi jangan hanya menggunakannya karena OOP adalah tren.

Jendral saya mengambil paradigma (dan mengapa tidak satu pun dari tiga paradigma utama adalah cara yang benar atau cara yang salah untuk memprogram):

Pemrograman prosedural baik ketika Anda memiliki masalah yang sederhana di tingkat tinggi (meskipun mungkin rumit di tingkat rendah) dan ingin menulis kode linier yang sesuai dan sederhana. Ini bisa dibilang lebih mudah untuk ditulis dan dipahami daripada OO dan fungsional jika masalahnya tidak membutuhkan decoupling yang kuat di mana pun. Contoh: Kode numerik, sebagian besar skrip kecil, sebagian kecil subproblem setelah Anda menguraikannya menggunakan OO atau fungsional.

Kode berorientasi objek adalah baik ketika Anda perlu memisahkan masalah karena Anda mungkin memiliki lebih dari satu implementasi beberapa masalah. Contoh: Sebagian besar perangkat lunak bisnis besar. Anda dapat, misalnya, ingin memisahkan logika bisnis dari logika presentasi karena mereka mungkin perlu berubah secara mandiri.

Pemrograman gaya fungsional bagus ketika Anda membutuhkan pemisahan mekanisme yang kuat dari kebijakan. Memiliki fungsi mekanisme yang menerima fungsi kebijakan adalah pola yang bagus. (Saya mempelajarinya dengan melihat modul std.algorithm bahasa pemrograman D.) Mengabstraksi keadaan yang bisa berubah pada batas antara kebijakan dan kode mekanisme umumnya membuat API lebih mudah untuk dipikirkan . Jika keadaan dapat diubah digunakan secara pribadi di dalam keduanya, ini adalah detail implementasi. Kekuatan lain pemrograman fungsional adalah konkurensi, untuk alasan yang jelas.

Kode tidak pernah "membutuhkan OOP". Itu programmer, sejauh mereka mampu berpikir dalam mode yang berbeda, yang membayangkan bahwa masalah khusus ini atau itu "membutuhkan" $ PARADIGM atau paling baik diselesaikan dengan cara itu.

Sering terjadi bahwa programmer yang hanya tahu satu paradigma berpikir bahwa paradigma mereka adalah yang terbesar. Satu ukuran cocok untuk semua, dan kita semua harus tidur di tempat tidur Procrustes, jika ini atau itu sedang modis.

Anda hanya harus mengubah proyek Anda menjadi OOP jika ada indikasi yang jelas akan kebutuhan untuk OOP. Skenario yang memungkinkan terjadinya hal ini adalah (antara lain):

• meningkatkan proyek
• menambahkan lebih banyak pengembang ke tim

dan bahkan dalam skenario ini mungkin masih tidak perlu mengubah proyek Anda menjadi OOP.

Keduanya bisa baik, keduanya bisa buruk. Tetapi perkuatan satu agar terlihat seperti yang lain tidak pernah merupakan ide yang baik.

Jika Anda berpikir kembali mengapa OO ditemukan, Anda akan melihat bahwa Anda tidak membutuhkan OOP sama sekali, tetapi kadang-kadang itu membuat hidup Anda jauh lebih mudah.

Kembali pada zaman C coding, sebuah program yang sangat besar bisa menjadi sangat berantakan dan sulit untuk terus bekerja. Jadi mereka menemukan cara untuk memecahnya menjadi potongan modular. OOP mengambil pendekatan ini dan membuatnya lebih modular, menempatkan data dengan potongan-potongan logika program sehingga mereka lebih terpisah dari sisa kode.

Hal ini memungkinkan Anda untuk menulis program yang lebih besar dan lebih besar, aman karena Anda telah mengubah tugas besar gajah Anda menjadi seratus tugas berukuran tikus. Bonus tambahan adalah Anda dapat mengambil beberapa 'tikus' ini dan menggunakannya kembali di program lain!

Tentu saja, dunia nyata tidak seperti itu, dan penggunaan kembali objek tidak pernah benar-benar terjebak dalam cara yang dimaksudkan, tetapi itu tidak berarti itu adalah paradigma yang tidak berguna.

Apa yang tidak berguna adalah ketergantungan yang berlebihan pada kedua gaya pengkodean. Siapa pun yang melakukan OO dengan seribu kelas kecil dan tidak signifikan tidak benar-benar melakukannya dengan benar - mereka membuat mimpi buruk pemeliharaan untuk diri mereka sendiri (atau orang lain). Siapa pun yang menulis aplikasi prosedural yang hanya 3 fungsi juga membuat hidup menjadi sulit. Cara terbaik adalah middlle ground, objek besar-ish (kadang-kadang disebut komponen yang mana kita melihat sekali waktu) yang dapat memberikan cukup banyak kode yang berdiri sendiri dan data yang jauh lebih mungkin untuk digunakan kembali dalam isolasi dari sisa aplikasi Anda.

Saran saya untuk waktu berikutnya: cobalah menulis kode prosedural Anda yang biasa, tetapi buat satu objek dari struktur data utama Anda. Lihat bagaimana Anda menemukan bahwa bekerja dengannya lebih mudah daripada mengirimkan data dari satu fungsi ke fungsi lainnya.

Kode saya tidak memerlukan fitur OOP [enkapsulasi, pewarisan pada dasarnya ...]!

Bagaimana Anda tahu bahwa?

Apakah Anda perlu mempertahankan proyek ini? Apakah ada fitur baru yang direncanakan? Akan ada orang lain yang akan berkembang bersama Anda? Apakah kamu mengulangi dirimu sendiri? Apakah kode sulit dipahami?

Jika jawabannya "ya", daripada mungkin Anda harus mulai berpikir tentang membuat kerangka OOP dan pergi dengan cara ini.