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.