Pemrograman Berorientasi Non-Obyek dalam Bahasa Berorientasi Obyek [ditutup]


15

Baru-baru ini saya ditugaskan untuk membuat kalkulator dengan penambahan fungsi, pengurangan, perkalian, pembagian, dan penggunaan daya Pemrograman Berorientasi Objek . Saya berhasil menyelesaikan tugas ini. Namun setelah itu saya memprogram ulang seluruh program tanpa menggunakan teknik / metode Object Oriented .

Hal yang saya perhatikan bahwa panjang kode saya berkurang cukup signifikan dan cukup dimengerti. Jadi pertanyaan saya di sini adalah kapan saya harus menggunakan Pemrograman Berorientasi Objek? Apakah boleh membuat program tanpa Orientasi Objek dalam Bahasa Berorientasi Objek? Mohon bantu saya untuk yang ini.

PS: Saya tidak meminta di sini untuk memberi tahu saya kelebihan Pemrograman Berorientasi Objek daripada pemrograman prosedural.


12
Sama sekali tidak ada alasan untuk menghindari penerapan teknik yang berbeda sesuai kebutuhan. Anda sebagai programmer harus mempertimbangkan pro dan kontra berdasarkan kasus per kasus. Cukup sering karena gaya pribadi.
ChaosPandion

3
Saya tidak pernah mengalami masalah. Bahasa itu hampir selalu alat yang ditentukan diberikan tim dan / atau arsitektur lainnya.


8
Menerapkan program yang sama dengan dan tanpa teknik OO adalah latihan yang baik untuk mempelajari sesuatu, saya tidak bisa mengerti mengapa beberapa orang di sini tampaknya menyangkal ini atau merendahkan Anda. Tetapi masalah dengan pertanyaan Anda adalah bahwa sudah ditanyakan di sini lebih dari sekali, dalam berbagai bentuk. Dan meskipun Anda menyangkalnya, Anda sedang bertanya tentang manfaat dari Object Oriented Programming lebih pemrograman prosedural. Dan C ++ bukan bahasa OO, itu adalah bahasa hibrida.
Doc Brown

3
Tambahkan fitur yang menampilkan rumus yang Anda masukkan dan kemudian tambahkan fungsi akar kuadrat (Jangan lakukan ini terlebih dahulu, itu akan curang.) Dan beri tahu kami pendapat Anda.
JeffO

Jawaban:


25

C ++ bukan "hanya" bahasa OO, itu adalah bahasa multi-paradigma. Jadi itu memungkinkan Anda untuk memutuskan untuk atau menentang pemrograman OO, atau mencampur keduanya. Menggunakan teknik OO menambah lebih banyak struktur untuk program Anda - dari mana Anda akan mendapat manfaat ketika program Anda mencapai ukuran atau kompleksitas tertentu. Struktur tambahan ini, bagaimanapun, datang untuk harga baris kode tambahan. Jadi untuk program "kecil" cara terbaik untuk pergi adalah sering menerapkannya dalam gaya non-OO terlebih dahulu, dan menambahkan lebih banyak teknik OO kemudian ketika program mulai tumbuh selama bertahun-tahun (yang mungkin tidak akan terjadi "latihan" "Program, tetapi merupakan siklus hidup khas untuk banyak program bisnis).

Bagian yang sulit adalah jangan sampai ketinggalan waktu ketika kompleksitas program Anda mencapai ukuran yang menuntut lebih banyak struktur. Kalau tidak, Anda akan berakhir dengan tumpukan kode spageti.


Jika program "latihan" sederhana mulai berkembang, cara terbaik adalah mengimplementasikannya sedemikian rupa sehingga dapat difaktorkan kembali sesudahnya. Terima kasih telah berbagi itu :) +1
FaizanRabbani

@CarlSmith: tentu saja. Tetapi ketika saya menulis jawaban saya, saya mencoba untuk fokus pada poin dan skala dari pertanyaan yang sebenarnya.
Doc Brown

10

Bagaimana pemrogram profesional membuat penilaian menghimbau apakah akan mengikuti OOP atau tidak? Ini akan sangat membantu saya.

Bagi saya, ada dua poin keputusan. Pertama, kadang-kadang akan terlihat jelas di awal. Akan ada banyak tipe serupa yang semuanya berbagi metode umum yang sangat berbeda dalam detail implementasi mereka. Misalnya, saya sedang membangun sistem alur kerja, dan saya membutuhkan kemampuan untuk mengimplementasikan tugas-tugas sewenang-wenang. Untuk menjalankan tugas, saya menerapkan kelas dasar tempat setiap tugas diwarisi, dengan Execute()metode abstrak. Kelas-kelas yang diwariskan menyediakan implementasi, tetapi sistem alur kerja dapat memulai eksekusi tanpa mengetahui apa pun tentang jenis tugas apa yang sedang dijalankan.

Sebagian besar proyek tidak begitu jelas. Poin keputusan kedua adalah ketika subset proyek telah berkembang menjadi kusut besar pernyataan if-then atau pernyataan switch-case, dan terutama ketika pernyataan if-then tersebut membutuhkan banyak kode pengaturan untuk berjalan dengan benar. Saya merasa diri saya mulai kehilangan logika dari apa yang saya coba capai, dan kode mulai terasa rapuh. Pada titik itu, biasanya merupakan tanda bahwa sudah waktunya untuk mengubah kode menjadi kelas dasar dengan implementasi spesifik.

Sebagian besar beralih ke gaya berorientasi objek yang bertentangan dengan gaya fungsional mengkonversi pernyataan if-then menjadi pernyataan "jalankan tindakan ini". Alih-alih satu set besar pernyataan if-then, Anda hanya memberi tahu kode untuk menjalankan aksinya. Tindakan mana yang sebenarnya dijalankan tergantung pada implementasi yang Anda berikan.

Sebagai contoh, inilah gaya fungsional dalam pseudocode gaya-C #:

if ( action == "email" ) { 
    callEmailFunction(userInfo);
}
else if ( action == "sms" ) { 
    callSmsFunction(userInfo);
}
else if ( action == "web" ) { 
    endpoint = "http://127.0.0.1/confirm";
    confirmWeb(endpoint, userinfo);
} 
...

Tapi mungkin Anda bisa menulis ulang untuk sesuatu seperti ini:

interface IConfirmable {
    void Confirm(UserInfo userinfo);
}

public class ConfirmEmail : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmSms : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmWeb : IConfirmable { 
    // this is a constructor
    public ConfirmWeb(string endpoint) { 
        ...
    }

    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via web
    }
} 

Dan kemudian kode itu sendiri:

// An implementation that decides which implementation of the base class to use
// This replaces the if-then statements in the functional programmming.
IConfirmable confirmer = ConfirmerFactory.GetConfirmer();

// get the userinfo however you get it, 
// which would be the same way you get it in the functional example.
UserInfo userinfo = ...;

// perform the action.
confirmer.Confirm(userinfo);

Sekarang, ketika ada sangat sedikit kode di dalam if-then, ini terlihat seperti banyak pekerjaan yang tidak mendapatkan manfaat. Dan ketika ada sangat sedikit kode di if-then, itu benar: itu banyak pekerjaan untuk kode yang lebih sulit untuk dipahami.

Tetapi gaya berorientasi objek benar-benar bersinar ketika Anda memiliki lebih dari satu tindakan daripada hanya Confirm()metode yang perlu dilakukan. Mungkin Anda memiliki rutin inisialisasi, tiga atau lebih metode tindakan yang dapat dijalankan, dan sebuah Cleanup()metode. Algoritma basis identik, kecuali itu membuat panggilannya menjadi objek yang sesuai yang menerapkan kelas dasar umum. Sekarang Anda mulai melihat manfaat nyata untuk gaya berorientasi objek: algoritma dasar lebih mudah dibaca daripada jika itu memeriksa pernyataan if-then pada setiap langkah.


+1 untuk analisis terperinci. :) Saya punya beberapa pemikiran tentang ini.
FaizanRabbani

1
Selain itu, tolong berhenti memposting komentar "terima kasih" pada setiap jawaban. Kami lebih suka fokus pada pertanyaan dan jawaban yang adil, bukan diskusi.
Philip Kendall

5
Contoh itu lebih penting daripada fungsional.
OrangeDog


1
Hanya sebuah catatan, ketika Anda condong ke arah sekelompok if / else atau beralih pernyataan, itu selalu merupakan opsi untuk mempertimbangkan semacam tabel pengamatan. Jadi cara lain untuk menulis ulang yang sejalan var dict = new Dictionary<string,Action<UserInfo>{ { "email", callEmailFunction }, { "sms", callSmsFunction } }; dict[ action ]( userInfo );(dict bisa statis, penanganan kesalahan dihilangkan)
stijn

3

Ya, sangat normal untuk menggunakan kode gaya lama, asalkan ruang lingkup proyek Anda terkenal atau terbatas. Jika Anda berencana untuk memperpanjang program atau proyek Anda OOP adalah salah satu cara untuk pergi, karena Anda dapat mempertahankan dan memperluas kode Anda dengan mulus, di sisi lain jika Anda merencanakannya dan sampai pada kesimpulan bahwa Anda tidak akan pernah merencanakan diperpanjang dari proyek yang Anda buat kemudian menulis kode tanpa OOP sudah cukup. Itu tidak berarti jika Anda menggunakan pendekatan non-OOP, Anda tidak pernah dapat memutakhirkan proyek Anda, tetapi itu akan menjadi hal yang membosankan untuk dilakukan. OOP adalah untuk membantu kita memvisualisasikan konsep kita seolah-olah itu adalah organisme kehidupan nyata karena kita memahami yang lebih baik daripada yang lain.


1
"Itu tidak berarti jika Anda menggunakan pendekatan non-OOP, Anda tidak pernah dapat memutakhirkan proyek Anda, tetapi itu akan menjadi hal yang membosankan untuk dilakukan.": OOP membantu memperpanjang proyek Anda ketika sebagian besar ekstensi melibatkan penambahan kelas baru (misalnya menambahkan widget baru ke a GUI). Ketika sebagian besar ekstensi melibatkan penambahan operasi baru, maka desain prosedural dapat lebih efektif.
Giorgio

1
Sejak kapan "tidak berorientasi objek" disebut "gaya lama"?
DanielSank
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.