Kebetulan proyek terhenti, dan pengembangan lebih lanjut menjadi tidak mungkin. Tidak jarang, alasan kegagalan tersebut adalah arsitektur yang gagal diletakkan pada awal pengembangan. Atau apakah Anda harus mengamati perselisihan tentang mana di antara "dua kursi" yang lebih baik, atau mungkin bahkan berpartisipasi dan tidak dengan tulus memahami bagaimana lawan Anda bisa berpikir begitu !?
Maka kami akan berusaha untuk tidak memahami banyak abstraksi, dari mana mereka berasal dan apa yang harus dilakukan dengan mereka.
Menurut Wikipedia, Abstraksi adalah generalisasi teoretis sebagai hasil dari abstraksi. Pada gilirannya, abstraksi adalah gangguan dalam proses kognisi dari pihak-pihak yang tidak penting, sifat-sifat, hubungan-hubungan suatu objek (objek atau fenomena) untuk menyoroti fitur-fitur esensial dan teratur mereka.
Dari definisi tersebut kita dapat menyimpulkan bahwa hanya bermakna yang bisa menjadi abstraksi. Dalam hal ini, persepsi hanyalah proyeksi dari dunia nyata. Ternyata semua refleksi pada yang nyata adalah refleksi pada model kita yang sebenarnya.
Abstraksi membentuk hierarki, dan dapat diidentifikasi dengan kedua entitas pribadi dan menggabungkan entitas serupa ke dalam abstraksi tingkat yang lebih tinggi.
Abstraksi kesadaran
Selain prisma persepsi, model kami juga mengalami distorsi lain: entitas nyata sangat kompleks dan memiliki aspek dan parameter yang berbeda. Ketika berpikir atau berbicara tentang sesuatu, selalu ada konteks di mana model ada. Dan kadang-kadang terjadi bahwa lawan bicara dari konteks ini berbeda. Dan to top it off, ada atau tidak adanya pengalaman (global) mengarah ke perubahan yang lebih besar dalam model kami sesuai dengan pengalaman ini. Akibatnya, dua orang yang berbeda dapat memiliki persepsi yang sangat berbeda tentang entitas yang sama di dunia nyata.
Ternyata setiap orang terus-menerus berurusan dengan abstraksi, masih harus belajar cara melihat dan mengelolanya dengan jelas. Seseorang dapat mengajukan tesis bahwa kode program adalah simulasi pemikiran berdasarkan abstraksi formal. Karena itu, menurut saya, pengembangan perangkat lunak adalah salah satu simulator terbaik untuk memompa pemikiran abstrak.
Abstraksi dalam pengembangan
Antarmuka pemrograman mungkin adalah abstraksi formal yang paling jelas. Semua berlebihan terpotong dan hanya "apa yang dilakukannya" tetap tanpa "bagaimana kerjanya".
Dengan mengimplementasikan antarmuka, kami membuat model perilaku atau interaksi yang lebih realistis, yang sudah dapat menjawab pertanyaan "bagaimana." Dengan menggabungkan antarmuka satu sama lain, kita dapat membuat arsitektur kode umum. Dengan keterampilan dan ketangkasan yang tepat, arsitektur yang dibuat dengan cara ini akan mempertahankan strukturnya di masa depan. Sementara implementasi antarmuka komposit dapat berubah melampaui pengakuan.
Arsitektur ini menyederhanakan beberapa poin dalam pekerjaan. Pengujian unit dilakukan dengan menulis implementasi pengujian abstraksi "tetangga" dan metode pengujian yang membandingkan input dan output. Insulasi modul memungkinkan Anda untuk melakukan refactoring dengan aman. Selain itu, jika refactoring tidak berhasil dan semuanya rusak, maka Anda harus memutar kembali hanya satu modul. Modul yang cukup abstrak dapat digunakan untuk tugas yang serupa tetapi berbeda. Pada saat yang sama, satu implementasi yang buruk tidak akan mempengaruhi pekerjaan orang lain - isolasi govnokod.
ContohAda modul untuk memproses input data, ada beberapa opsi untuk memperolehnya: dari database; dari file; oleh http. Masalah ini dapat diselesaikan dengan menyoroti antarmuka umum untuk menerima data dan membuat implementasi untuk setiap saluran dan saluran data untuk pengujian. Sekarang satu penangan dapat memecahkan beberapa masalah serupa menggunakan parameter "saluran data". Dan jika ternyata salah satu implementasinya adalah kurva, maka dapat diulang untuk mempengaruhi modul lain.
Abstraksi tidak lagi diperlukan
Tidak ada solusi yang sempurna, dan dengan abstraksi, segala sesuatunya tidak begitu lancar. Pertama, abstraksi adalah subyektif, mereka dapat menyebabkan perdebatan tentang di mana seseorang memulai dan yang lainnya dimulai. Ada juga masalah abstraksi yang berlebihan, ketika abstraksi yang berbeda dibuat untuk setiap jenis dan nada suara bersin. Kedua, pendekatan ini meningkatkan kompleksitas kode dengan menambahkan entitas baru dan tingkat hierarki baru. Saya yakin bahwa masih akan ada kekurangan dari pendekatan ini, beberapa dari mereka akan subjektif, sebagian situasional, tetapi akan ada
Harus ada keseimbangan dalam segala hal. Bagi saya sendiri, saya menyimpulkan memo berikut.
- Jika Anda menulis modul besar dan penting - lebih baik melepaskannya.
- Jika modul banyak digunakan dan / atau di tempat yang berbeda, lebih baik menyembunyikannya di belakang abstraksi.
- Jika modul harus didistribusikan sebagai perpustakaan terpisah, lebih baik menggunakan abstraksi.
- Jika dimungkinkan untuk mengubah algoritma atau jalur interaksi, lebih baik untuk mengimplementasikan interaksi abstraksi.
- Jika kelas digunakan di kelas lain dan tidak di tempat lain - Anda dapat berpikir tentang menggabungkan mereka atau membiarkannya apa adanya.
- Jika ini adalah tugas "satu kali" yang kecil - lebih baik tidak repot dengan kerumitannya.
- Jika ini adalah modul yang kemungkinan besar tidak akan pernah berubah - Anda dapat menampilkan antarmuka dan lebih baik meninggalkan semuanya karena ada di dalamnya.
Total
Abstraksi adalah alat yang dibangun ke dalam kesadaran kita, seperti yang lain mereka memiliki pro dan kontra, tetapi mengetahui alternatif hanya membantu menemukan cara yang lebih baik.