The Blob

The Blob

Antipattern Nama: The Blob
Disebut Juga Sebagai: Winnebago dan mengetahui Kelas
Kebanyakan Skala Sering: Aplikasi
Refactored Solusi Nama: Refactoring dari Tanggung Jawab
Refactored Solusi Jenis: Software
Penyebab root: Sloth, Haste
Angkatan seimbang: Pengelolaan Fungsi, Kinerja, Kompleksitas
Anekdot Bukti: "ini adalah kelas yang benar-benar jantung arsitektur kita.””

Latarbelakang
    Apakah Anda ingat film hitam-putih asliBlob? Mungkin Anda hanya melihat remake baru-baru ini. Dalam kedua kasus, alur cerita hampir sama: Sebuah drip berukuran, jelly seperti bentuk kehidupan alien dari luar angkasaentah bagaimana membuatnya ke Bumi.
Setiap kali makan hal jelly (biasanyapenduduk dunia tidak curiga), tumbuh. Sementara itu, penduduk dunia percaya panik dan mengabaikan salah satu ilmuwan gila yang tahu apa yang terjadi. Banyak lebih banyak orang yang dimakan sebelum mereka datang ke indra mereka. Akhirnya, Blob tumbuhbegitu besar sehingga mengancam untukmenghapus seluruh planet.
Film ini adalah analogi yang baik untuk Blob Anti Pola, yang telah dikenal untuk mengkonsumsi seluruh arsitektur berorientasi objek.

 

Bentuk umum
    The Blob ditemukan dalam desain di mana satu kelas memonopoli pengolahan, dan kelas-kelas lain terutama merangkum data. Antipattern ini ditandai dengan diagram kelas terdiri dari kelas controller kompleks tunggal dikelilingi oleh kelas data sederhana. Masalah utama di sini adalah bahwa sebagian besar tanggung jawab yang dialokasikan untuk satu kelas.

    Secara umum, Blob adalah desain prosedural meskipun mungkin diwakili menggunakan notasi objek dan diimplementasikan dalam bahasa berorientasi objek. Sebuah desain prosedural memisahkan proses dari data, sedangkan desain berorientasi obyek menggabungkan proses dan data model, bersama dengan partisi.

    The Blob berisi sebagian besar proses, dan benda-benda lain berisi data. Arsitektur dengan Blob telah dipisahkan proses dari data; dengan kata lain, mereka adalah prosedural bergaya daripada arsitektur berorientasi objek.

 

   The Blob dapat menjadi hasil dari persyaratan yang tidak pantas alokasi. Sebagai contoh, Blob mungkin modul perangkat lunak yang diberikan tanggung jawab yang tumpang tindih bagian yang paling lain dari sistem untuk sistem kontrol atau manajemen sistem.

    The Blob juga sering hasil dari pembangunan berulang di mana bukti-of-konsep kode berkembang dari waktu ke waktu menjadi prototipe, dan akhirnya, sistem produksi. Hal ini sering diperparah oleh penggunaan bahasa terutama GUI-sentris pemrograman, seperti Visual Basic, yang memungkinkan bentuk sederhana untuk berkembang fungsinya, dan karena itu tujuan, selama pengembangan
 inkremental atau prototyping.

   Alokasi tanggung jawab tidak dipartisi selama sistem evolusi, sehingga satu modul menjadi dominan. Blob yang sering disertai dengan kode yang tidak perlu, sehingga sulit untuk membedakan antara fungsi yang berguna dari Kelas Blob dan kode tidak-lagi-digunakan (lihat Lava Flow antipattern).

Gejala Dan Konsekuensi
   Kelas tunggal dengan sejumlah besar atribut, operasi, atau keduanya. Sebuah kelas dengan 60 atau lebih atribut dan operasi biasanya menunjukkan adanya Blob yang
Sebuah koleksi yang berbeda dari atribut yang tidak terkait dan operasi dikemas dalam satu kelas. Kurangnya keseluruhan kekompakan atribut dan operasi khas dari Blob tersebut.
Sebuah kelas controller tunggal dengan terkait kelas sederhana, data-objek.
Tidak adanya desain berorientasi objek. Sebuah loop program utama dalam kelas Blob terkait dengan objek data yang relatif pasif. Kelas controller tunggal sering hampir merangkum aplikasi seluruh fungsi, seperti sebuah program utama prosedural.

    Sebuah desain warisan bermigrasi yang belum benar refactored ke arsitektur berorientasi objek.
The Blob kompromi keuntungan yang melekat pada desain berorientasi objek. Misalnya, The Blob membatasi kemampuan untuk memodifikasi sistem tanpa mempengaruhi fungsi dari benda dikemas lainnya. Modifikasi Blob mempengaruhi software luas dalam enkapsulasi Blob itu. Modifikasi untuk benda-benda lain dalam sistem juga mungkin memiliki dampak pada perangkat lunak Blob itu.
The Blob Kelas biasanya terlalu kompleks untuk digunakan kembali dan pengujian. Mungkin tidak efisien, atau memperkenalkan kompleksitas yang berlebihan untuk menggunakan kembali Blob untuk subset dari fungsinya.

    The Blob Kelas mungkin mahal untuk load ke memori, menggunakan sumber daya yang berlebihan, bahkan untuk operasi sederhana.

Penyebab khas
   Kurangnya arsitektur berorientasi objek. Para desainer mungkin tidak memiliki pemahaman yang memadai tentang prinsip-prinsip berorientasi objek. Atau, tim mungkin tidak memiliki keterampilan abstraksi yang tepat.

Kurangnya (ada) arsitektur. Tidak adanya definisi dari komponen sistem, interaksi mereka, dan penggunaan spesifik bahasa pemrograman yang dipilih. Hal ini memungkinkan program untuk berkembang dalam mode ad hoc karena bahasa pemrograman yang digunakan untuk selain tujuan mereka dimaksudkan.

    Kurangnya penegakan arsitektur. Kadang-kadang antipattern ini tumbuh sengaja, bahkan setelah arsitektur wajar direncanakan. Ini mungkin hasil dari tinjauan arsitektur yang tidak memadai sebagai pembangunan berlangsung. Hal ini terutama lazim dengan tim pengembangan baru untuk objek orientasi.

    Intervensi terlalu terbatas. Dalam proyek-proyek berulang, pengembang cenderung untuk menambahkan potongan-potongan kecil dari fungsionalitas untuk kelas pekerja yang ada, daripada menambah kelas baru, atau merevisi hirarki kelas untuk alokasi lebih efektif dari tanggung jawab.
Ditentukan bencana. Kadang-kadang hasil Blob dari persyaratan cara yang ditentukan. Jika persyaratan mendikte solusi prosedural, maka komitmen arsitektur dapat dibuat selama analisis persyaratan yang sulit untuk berubah. Mendefinisikan arsitektur sistem sebagai bagian dari analisis kebutuhan biasanya tidak pantas, dan sering mengarah ke Blob antipattern, atau lebih buruk.

dikenal pengecualian
   The Blob antipattern diterima ketika membungkus sistem warisan. Tidak ada partisi perangkat lunak yang diperlukan, hanya lapisan akhir kode untuk membuat sistem warisan lebih mudah diakses.

Solusi refactored
    Seperti sebagian besar antipatterns di bagian ini, solusinya melibatkan bentuk refactoring. Kuncinya adalah untuk memindahkan perilaku jauh dari Blob itu. Mungkin tepat untuk mengalokasikan perilaku untuk beberapa objek data dikemas dalam cara yang membuat benda-benda ini lebih mampu dan Blob kurang kompleks. Metode untuk refactoring tanggung jawab digambarkan sebagai berikut: Mengidentifikasi atau mengkategorikan atribut terkait dan operasi sesuai dengan kontrak. Kontrak ini harus kohesif dalam bahwa mereka semua langsung berhubungan dengan fokus umum, perilaku, atau fungsi dalam sistem secara keseluruhan. Sebagai contoh, diagram arsitektur sistem perpustakaan diwakili dengan kelas Blob potensial disebut PERPUSTAKAAN.

   Dalam contoh yang ditunjukkan pada gambar 1, kelas PERPUSTAKAAN merangkum jumlah total dari semua fungsi sistem. Oleh karena itu, langkah pertama adalah untuk mengidentifikasi set kohesif operasi dan atribut yang mewakili kontrak. Dalam hal ini, kita bisa berkumpul operasi yang berhubungan dengan manajemen katalog, seperti Urutkan Katalog dan Search_Catalog. Kami juga bisa mengidentifikasi semua operasi dan atribut yang berkaitan dengan masing-masing item, seperti Print_Item, Delete_Item, dan sebagainya

 

Gambar 1

 

Gambar 2

   Langkah kedua adalah untuk mencari "rumah alami" untuk ini koleksi berbasis kontrak fungsi dan kemudian bermigrasi mereka di sana. Dalam contoh ini, kita berkumpul operasi yang berhubungan dengan katalog dan bermigrasi mereka dari kelas PERPUSTAKAAN dan memindahkan mereka ke kelas KATALOG. Kami melakukan hal yang sama dengan operasi dan atribut yang berkaitan dengan item, memindahkan mereka ke kelas ITEM. Ini baik menyederhanakan kelas PERPUSTAKAAN dan membuat ITEM KATALOG dan kelas lebih dari tabel data dienkapsulasi sederhana. Hasilnya adalah desain berorientasi objek yang lebih baik.

 

Gambar 3

    Langkah ketiga adalah untuk menghapus semua "jauh-digabungkan," atau berlebihan, asosiasi tidak langsung. Dalam contoh, kelasITEM awalnya jauh-digabungkan ke kelas PERPUSTAKAANdalam setiap item benar-benar milik KATALOG, yang pada gilirannya milik PERPUSTAKAAN a.

Berikutnya, dimana tepat, kita bermigrasi rekanuntuk kelas turunan ke kelas dasar umum. Dalam contoh, setelah jauh-coupling telah dihapus antara PERPUSTAKAANdan ITEM kelas, kita perlu untuk bermigrasi item untuk katalog, seperti yang ditunjukkan pada gambar 4.

 

Gambar4

   Akhirnya, kita menghapus semua asosiasi sementara, menggantinya sesuai dengan jenis specifieruntuk atribut dan argumen operasi. Dalam contoh kita, sebuah Check_Out_Itematau Cari UntukBarang akan menjadi proses sementara, dan bisapindah ke kelas sementaraterpisah dengan atribut lokal yang menetapkan lokasi atau pencarian kriteria khusus untuk contoh spesifik daricheck-out atau pencarian.

Variasi
    Kadang-kadang, dengan sistem yang terdiri dari kelas Blob dan objek data pendukungnya, terlalu banyak pekerjaan yang telah diinvestasikan untuk memungkinkan refactoring arsitektur kelas. Sebuah pendekatan alternatif mungkin tersedia yang menyediakan solusi "80%".

    Alih-alih refactoring bottom-up dari seluruh hirarki kelas, dimungkinkan untuk mengurangi kelas Blob dari controller untuk kelas koordinator. Kelas Blob asli mengelola fungsi sistem; kelas data diperpanjang dengan beberapa pengolahan sendiri.

    Kelas Data beroperasi pada arah kelas koordinator dimodifikasi. Proses ini memungkinkan retensi hirarki kelas asli, kecuali untuk migrasi dari pengolahan fungsi dari kelas Blob untuk beberapa kelas data dienkapsulasi.

    Riel mengidentifikasi dua bentuk utama dari Blob antipattern. Dia menyebut dua bentuk ini Allah Kelas: Form Perilaku dan Form Data

    Formulir Perilaku adalah obyek yang berisi proses terpusat yang berinteraksi dengan sebagian lain dari sistem. Formulir data adalah obyek yang berisi data bersama yang digunakan oleh sebagian besar benda-benda lain dalam sistem. Riel memperkenalkan sejumlah heuristik berorientasi objek untuk mendeteksi ing dan refactoring Allah Kelas desain.

Berlakunya Untuk Pandangan Dan TimbanganLainnya
    Kedua sudut pandang arsitektur dan manajerial memainkan peran kunci dalam pencegahan awal dari Blob antipattern. Penghindaran dari Blob mungkin memerlukan kebijakan yang sedang berlangsung dari arsitektur untuk menjamin distribusi yang memadaidari tanggung jawab.
Ini adalah melalui sudut pandang arsitektur bahwa Blobmuncul diakui. Dengananalisis yang matang berorientasi obyek dan proses desain, dan manajer peringatan yang mengerti desain, pengembang dapatmencegah budidaya Blob a.

 
    Faktor yang paling penting adalah bahwa, dalam banyak kasus, itu jauh lebih murah untuk membuat desain yang sesuai daripada ulang desain setelah implementasi. Muka investasidalam arsitektur dan tim pendidikan yang baik dapat memastikan proyek terhadap Blobdan paling antipatterns lainnya.
Meminta seorang penjual asuransi, dan diamungkin mengatakan kepada Anda bahwa sebagian besar asuransi yang dibeli setelah itu dibutuhkan oleh orang-orang yang miskintapi bijaksana.

Contoh
    Sebuah modul GUI yang dimaksudkan untuk antarmuka untuk modul pengolahan secara bertahap mengambil fungsi pengolahan modul latar belakang pengolahan. Contoh dari ini adalah layar PowerBuilder untuk data pelanggan entri / pengambilan. Layar dapat:

Menampilkan data.
Mengedit data.
Melakukan jenis validasi sederhana. Pengembang kemudian menambahkan fungsi untuk apa yang dimaksudkan untuk menjadi mesin keputusan:
Kompleks validasi.

    Algoritma yang menggunakan data divalidasi untuk menilai tindakan berikutnya.
Pengembang kemudian mendapat persyaratan baru untuk:
Memperpanjang GUI untuk tiga bentuk.
Buatlah naskah-driven (termasuk pengembangan mesin script).
Tambahkan algoritma baru untuk mesin keputusan.

    Pengembang meluas modul saat ini untuk menggabungkan semua fungsi ini. Jadi, bukannya mengembangkan beberapa modul, satu modul dikembangkan. Jika aplikasi yang dimaksud adalah architected dan dirancang, lebih mudah untuk mempertahankan dan memperluas.