Fungsional Dekomposisi antipattern

Fungsional Dekomposisi antipattern Nama: Dekomposisi fungsional Disebut Juga Sebagai: Tidak Berorientasi Objek antipattern "Tidak ada OO" Kebanyakan Skala Sering: Aplikasi Refactored Solusi Nama: Penyebab Proses Akar:: Object-Oriented Reengineering Refactored Solusi Jenis Ketamakan, Greed, Sloth seimbang Angkatan: Manajemen Kompleksitas, Ubah Bukti anekdotal: "Ini adalah rutin kami 'utama', di sini di kelas yang disebut PENDENGAR."

Latar belakang 
   Dekomposisi fungsional baik dalam lingkungan pemrograman prosedural. Itu bahkan berguna untuk memahami sifat modular dari aplikasi-skala yang lebih besar.
Sayangnya, hal itu tidak diterjemahkan langsung ke hirarki kelas, dan ini adalah di mana masalah dimulai. Dalam mendefinisikan antipattern ini, penulis mulai dengan pikiran asli Michael Aykroyd pada topik ini. Kami telah diformat ulang agar sesuai dengan template kita, dan diperpanjang agak dengan penjelasan dan diagram.

Bentuk umum
   Antipattern ini adalah hasil dari berpengalaman, pengembang non berorientasi objek yang merancang dan mengimplementasikan aplikasi dalam bahasa berorientasi objek. Ketika pengembang nyaman dengan "utama" rutin yang memanggil subrutin banyak, mereka mungkin cenderung membuat setiap subrutin kelas, mengabaikan hirarki kelas sama sekali (dan cukup banyak mengabaikan orientasi objek seluruhnya).

    Kode yang dihasilkan menyerupai bahasa struktural seperti Pascal atau FORTRAN dalam struktur kelas. Hal ini dapat sangat kompleks, sebagai pengembang prosedural pintar menemukan cara-cara yang sangat cerdas untuk meniru metode yang telah teruji dalam arsitektur berorientasi objek.

Anda akan bertemu kemungkinan besar Pola Anti ini di toko C yang baru-baru ini pergi ke C ++, atau telah mencoba untuk menggabungkan interface CORBA, atau baru saja dilaksanakan beberapa jenis alat obyek yang seharusnya untuk membantu mereka. Ini biasanya lebih murah dalam jangka panjang untuk menghabiskan uang pada pelatihan berorientasi objek atau hanya menyewa programmer baru yang berpikir dalam objek.

Gejala Dan Konsekuensi 

   Kelas dengan "fungsi" nama-nama seperti Hitung bunga atau Tampilan Tabel mungkin menunjukkan adanya antipattern ini. Semua atribut kelas pribadi dan hanya digunakan di dalam kelas. Kelas dengan satu tindakan seperti fungsi. Arsitektur sangat merosot yang benar-benar merindukan titik arsitektur berorientasi objek.  

   Benar-benar tidak leveraging dari prinsip-prinsip berorientasi objek seperti pewarisan dan polimorfisme. Ini bisa sangat mahal untuk mempertahankan (jika pernah bekerja di tempat pertama, tetapi tidak pernah meremehkan kecerdikan programmer tua yang perlahan-lahan kehilangan perlombaan teknologi). Tidak ada cara untuk mendokumentasikan jelas (atau bahkan menjelaskan) bagaimana sistem bekerja. Model kelas membuat benar-benar tidak masuk akal. Tidak ada harapan yang pernah mendapatkan penggunaan kembali perangkat lunak. Frustrasi dan putus asa pada bagian penguji.

Penyebab khas 

   Kurangnya pemahaman berorientasi objek. Pelaksana tidak "mendapatkannya." Hal ini cukup umum ketika pengembang beralih dari pemrograman dalam bahasa pemrograman berorientasi objek non untuk bahasa pemrograman berorientasi objek. Karena ada arsitektur, desain, dan implementasi perubahan paradigma, objek-orientasi dapat memakan waktu hingga tiga tahun untuk sebuah perusahaan untuk sepenuhnya mencapai. Kurangnya penegakan arsitektur. Ketika pelaksana clueless tentang orientasi objek, tidak peduli seberapa baik arsitektur telah dirancang; mereka tidak akan mengerti apa yang mereka lakukan. Dan tanpa pengawasan yang tepat, mereka biasanya akan menemukan cara untuk fudge sesuatu menggunakan teknik yang mereka tahu. Ditentukan bencana. Kadang-kadang, orang-orang yang menghasilkan spesifikasi dan persyaratan tidak selalu memiliki pengalaman nyata dengan sistem berorientasi objek. Jika sistem mereka tentukan membuat komitmen arsitektur sebelum analisis kebutuhan, dapat dan sering menyebabkan Anti Pola seperti Dekomposisi Fungsional.

Dikenal Pengecualian
    Fungsional Dekomposisi antipattern baik-baik saja ketika sebuah solusi berorientasi objek tidak diperlukan. Pengecualian ini dapat diperluas untuk menangani solusi yang murni fungsional di alam tetapi dibungkus untuk menyediakan sebuah antarmuka berorientasi objek untuk kode implementasi.
Solusi refactored

    Jika masih mungkin untuk memastikan apa persyaratan dasar untuk perangkat lunak, menentukan model analisis untuk perangkat lunak, untuk menjelaskan fitur penting dari perangkat lunak dari sudut pengguna pandang. Hal ini penting untuk menemukan motivasi yang mendasari banyak konstruksi perangkat lunak dalam basis kode tertentu, yang telah hilang dari waktu ke waktu. Untuk semua langkah dalam larutan penguraian antipattern Fungsional, menyediakan dokumentasi rinci tentang proses yang digunakan sebagai dasar untuk upaya pemeliharaan masa depan.

   Berikutnya, merumuskan model desain yang menggabungkan potongan-potongan penting dari sistem yang ada. Jangan fokus pada peningkatan model tetapi pada membangun dasar untuk menjelaskan sebanyak sistem mungkin.

   Idealnya, model desain akan membenarkan, atau setidaknya merasionalisasi, sebagian besar modul software. Mengembangkan model desain untuk basis kode yang ada adalah mencerahkan; memberikan wawasan tentang bagaimana sistem secara keseluruhan cocok bersama-sama. Hal ini wajar untuk mengharapkan bahwa beberapa bagian dari sistem yang ada untuk alasan tidak lagi dikenal dan yang tidak ada spekulasi yang wajar dapat dicoba.


Untuk kelas yang berada di luar model desain, gunakan panduan berikut:

    Jika kelas memiliki metode tunggal, cobalah untuk model yang lebih baik sebagai bagian dari kelas yang ada. Sering, kelas dirancang sebagai kelas pembantu ke kelas lain yang lebih baik yang digabungkan menjadi kelas dasar mereka membantu.
Mencoba untuk menggabungkan beberapa kelas menjadi kelas baru yang memenuhi tujuan desain. Tujuannya adalah untuk mengkonsolidasikan fungsi beberapa jenis ke dalam satu kelas yang menangkap konsep domain yang lebih luas daripada kelas yang lebih halus-grained sebelumnya. Misalnya, daripada memiliki kelas untuk mengatur akses perangkat, untuk menyaring informasi ke dan dari perangkat, dan untuk mengontrol perangkat, menggabungkan mereka ke dalam perangkat objek controller tunggal dengan metode yang melakukan kegiatan yang sebelumnya tersebar di antara beberapa kelas.

    Jika kelas tidak mengandung informasi keadaan apapun, pertimbangkan menulis ulang sebagai fungsi. Berpotensi, beberapa bagian dari sistem dapat terbaik dimodelkan sebagai fungsi yang dapat diakses di seluruh berbagai bagian dari sistem tanpa pembatasan.

Memeriksa desain dan menemukan subsistem yang sama. Ini adalah kandidat reuse. Sebagai bagian dari program pemeliharaan, terlibat dalam refactoring dari basis kode untuk menggunakan kembali kode antara subsistem yang sama (lihat solusi Spaghetti Kode untuk penjelasan rinci tentang refactoring software).

Contoh
Dekomposisi fungsional didasarkan pada fungsi diskrit untuk tujuan manipulasi data, misalnya, penggunaan Jackson Structured Programming. Fungsi seringkali metode dalam lingkungan berorientasi objek. Partisi fungsi didasarkan pada paradigma yang berbeda, yang mengarah ke pengelompokan yang berbeda fungsi dan data yang terkait.

Contoh sederhana pada gambar di bawah ini menunjukkan versi fungsional skenario pinjaman pelanggan: 

• Menambahkan pelanggan baru.
• Memperbarui alamat pelanggan.
• Menghitung pinjaman untuk pelanggan.
• Menghitung bunga pinjaman.
• Menghitung jadwal pembayaran untuk pinjaman pelanggan.
• Mengubah jadwal pembayaran. 

   Angka berikutnya kemudian menunjukkan tampilan berorientasi objek dari aplikasi pinjaman pelanggan. Fungsi sebelumnya map untuk objek metode.

 

Solusi terkait
   Jika terlalu banyak pekerjaan telah diinvestasikan dalam sistem terganggu oleh Fungsional dekomposisi, Anda mungkin dapat menyelamatkan hal dengan mengambil pendekatan serupa dengan pendekatan alternatif dibahas dalam Blob antipattern.

Alih-alih refactoring bottom-up dari hirarki seluruh kelas, Anda mungkin dapat memperpanjang "rutin utama" kelas untuk sebuah "koordinator" kelas yang mengelola semua atau sebagian besar fungsi sistem.

    Kelas fungsi kemudian dapat "dipijat" ke dalam kelas-kuasi-berorientasi objek dengan menggabungkan mereka dan beefing mereka untuk melaksanakan beberapa pengolahan sendiri di arah dimodifikasi "koordinator" kelas. Proses ini dapat mengakibatkan hirarki kelas yang lebih bisa diterapkan
Berlakunya Untuk Pandangan Dan Timbangan Lainnya

    Kedua sudut pandang arsitektur dan manajerial memainkan peran kunci dalam pencegahan baik awal atau kepolisian yang sedang berlangsung terhadap Fungsional penguraian antipattern. Jika arsitektur berorientasi objek yang benar pada awalnya direncanakan dan masalah terjadi pada tahap pengembangan, maka itu adalah tantangan manajemen untuk menegakkan arsitektur awal.

    Demikian juga, jika penyebabnya adalah kurangnya arsitektur yang salah pada awalnya, maka masih merupakan tantangan manajemen untuk mengenali ini, mengerem, dan mendapatkan bantuan-arsitektur cepat lebih murah.