Empat Strategi Untuk Menentukan Komponen Coding – Artikelnya menguraikan empat strategi berbeda untuk mengatur kode: menurut komponen , menurut kotak alat , menurut lapisan , dan menurut jenisnya . Saya pikir keempat ini membentuk semacam hierarki sehubungan dengan jenis kohesi mana yang mereka sukai dan menurut pengalaman saya, mereka mencakup sebagian besar kode dunia nyata yang pernah saya kerjakan, menyenangkan dan tidak. Ada banyak sekali kemungkinan strategi tetapi saya (untungnya) tidak pernah menemukan siapa pun yang mengatur paket ke dalam proyek berdasarkan tanggal pembuatan atau kelas ke dalam paket dengan huruf pertama.
Empat Strategi Untuk Menentukan Komponen Coding
binaryjs – Ketika satu unit kode tumbuh terlalu besar dan mengandung terlalu banyak elemen, itu menjadi sulit untuk dinavigasi, sulit untuk mendapatkan gambaran umum, dan sulit untuk dipahami: itu menjadi kompleks . Senjata utama kami melawan kompleksitas ini adalah membagi dan menaklukkan: kami membagi unit menjadi bagian-bagian yang lebih kecil yang dapat kami pahami secara terpisah. Untuk kelas, cukup dipahami bahwa ini harus dilakukan agar kita membuat objek logis yang menunjukkan kohesi yang baik dan cocok dengan model domain.
Baca Juga : Cara Terbaik untuk Mempelajari Cara Membuat Kode Gratis
Dengan proyek yang dikompilasi secara terpisah kita harus memutus dependensi melingkar dan mencoba memastikan bahwa mereka mengekspos antarmuka yang cukup logis dan stabil ke proyek lain. Pada tingkat di antara paket di Java atau ruang namadi C# ada lebih banyak variasi dan menurut pengalaman saya, banyak pengembang memilih strategi tanpa banyak pertimbangan mengapa strategi tertentu harus digunakan.
Tiga strategi pertama yang dijelaskan dalam artikel ini dapat digunakan di tingkat kelas , paket , atau proyek sedangkan yang terakhir — organisasi menurut jenisnya kurang lebih spesifik untuk tingkat paket.
Menurut Komponen
Pengorganisasian oleh komponen meminimalkan kompleksitas dengan menekankan kohesi eksternal dan internal unit kode, misalnya paket. Yang pertama berarti bahwa paket tersebut memiliki antarmuka minimal yang hanya memperlihatkan konsep yang sangat terkait dengan layanan yang disediakan komponen. Yang terakhir berarti bahwa kode dalam paket sangat terkait dan dengan demikian sangat terkait dengan layanan yang disediakan.
Banyak yang bisa dan telah ditulis tentang apa yang merupakan unit abstraksi yang baik dan mencakup bahkan sepotong itu akan membuat artikel ini terlalu panjang. Cukuplah untuk mengatakan bahwa prinsip – prinsip SOLID adalah tempat yang bagus untuk mulai belajar dan bahwa latihan dan refleksi tentang bagaimana segala sesuatunya berjalan dan mengapa itu mungkin adalah yang terpenting. Dalam artikel ini saya hanya akan membahas apa yang menurut pengalaman saya adalah satu-satunya alasan paling umum untuk kompleksitas yang merajalela dalam basis kode di mana orang benar-benar mencoba mengatur berbagai hal dengan membagi penaklukan: kegagalan untuk mengisolasi paket menjadi komponen.
Unit kode baru sering dibuat dengan mengidentifikasi subset fungsi yang terkandung dalam satu (atau lebih) paket yang ada dan membuat abstraksi baru dari kode yang sesuai, menghasilkan unit yang lebih banyak tetapi lebih kecil. Ini menciptakan kode yang terlihat lebih mudah dicerna tetapi sebagian besar hanya sebagai penutup jendela sampai langkah lebih lanjut diambil: manfaat dari pengurangan kompleksitas total tidak akan mengikuti kecuali Anda kemudian mengambil langkah menghilangkan dependensi.
Menurut pendapat saya paket yang memiliki ketergantungan timbal balik tidak boleh dianggap sebagai unit kode yang terpisah sama sekali karena tidak ada yang dapat dipahami secara terpisah dari yang lain. Dalam contoh di atas, mudah untuk membayangkan bahwa kelas Graph memiliki referensi ke GraphStorage di mana ia bertahan setiap kali telah berubah. Paket graph_storage tidak hanya bergantung pada banyak detail model domain paket graph yang seharusnya tidak diketahui, paket-paket tersebut juga tetap saling bergantung. Ketergantungan termudah untuk dihilangkan seringkali adalah dari paket baru ke yang lama:
Alasan paling penting mengapa ini adalah peningkatan adalah bahwa ketika membaca kode penyimpanan, seseorang sekarang dapat mengandalkan fakta bahwa satu-satunya hal yang perlu diketahui tentang apa yang disimpannya adalah apa yang ada di antarmuka Storable .
Langkah selanjutnya adalah menghilangkan ketergantungan langsung dari paket grafik ke paket penyimpanan. Hal ini misalnya dapat dilakukan dengan membuat antarmuka GraphPersister di sebelumnya dan memiliki paket tingkat yang lebih tinggi menyuntikkan implementasi adaptor ke dalam Graph . Dan sekali lagi, manfaat utama adalah bahwa rangkaian fungsi penyimpanan yang tepat yang menjadi sandaran paket grafik akan menjadi jelas.
Secara teori, proses ini mungkin terdengar cukup mudah, tetapi dibutuhkan banyak pengalaman untuk belajar mengidentifikasi komponen dan strategi yang sesuai untuk mengisolasinya. Sangat umum untuk memulai proses hanya untuk mengetahui bahwa Anda tidak mendapatkan abstraksi dengan benar dan harus mundur dari perubahan. Namun, imbalan untuk mengisolasi komponen dengan benar sangat bagus: kode yang mudah dipahami, mudah ditingkatkan, mudah diuji, dan — kebetulan — mudah digunakan kembali .
Dengan Toolbox
Organization by toolbox berfokus pada kohesi eksternal, menyediakan toolbox yang konsisten yang dapat dipilih konsumen. Strategi ini lebih lemah daripada pengorganisasian berdasarkan komponen karena menghilangkan persyaratan untuk kohesi internal yang kuat, misalnya bahwa semua konstituen saling terkait erat. Bagian-bagian dari kotak alat sering kali merupakan implementasi pelengkap dari antarmuka yang sama yang dapat dipilih atau digabungkan secara berguna, daripada berbagi banyak cara implementasi.
Pustaka koleksi biasanya diatur sebagai kotak peralatan dengan seperangkat implementasi pelengkap dari serangkaian antarmuka koleksi dengan berbagai karakteristik yang berkaitan dengan area seperti kompleksitas waktu dan konsumsi memori. Mungkin juga ada tema pemersatu ke kotak alat, seperti hanya berisi struktur data berbasis disk.
Pustaka logging tidak selalu merupakan kotak peralatan secara keseluruhan tetapi sering kali berisi kotak peralatan misalnya implementasi penulis log yang menargetkan tujuan yang berbeda.
Kotak peralatan muncul karena nyaman bagi konsumen dan setiap “alat” di dalam kotak tidak cukup besar untuk menjamin unitnya sendiri meskipun secara teknis independen. Setiap komponen dalam pustaka GUI mungkin, misalnya, layak mendapatkan paketnya sendiri, tetapi memberikan setiap proyeknya sendiri tidak perlu memberatkan. Demikian pula setiap implementasi koleksi mungkin cocok dalam satu kelas dan menempatkan semuanya dalam paket individu akan menjadi birokrasi yang tidak perlu. Setidaknya dalam kasus terakhir, implementasi koleksi tunggal yang tumbuh di luar beberapa kelas harus mendapatkan paketnya sendiri, mungkin kecuali untuk fasad tipis demi konsistensi eksternal.
Menurut Lapisan
Organization by layer mendukung kohesi alur kerja daripada mencoba untuk mengontrol kompleksitas dengan meminimalkan kopling lintas unit. Kode dibagi di sepanjang batas lapisan yang ditentukan oleh masalah seperti skenario penerapan atau area tanggung jawab kontributor. Strategi ini berbeda dari organisasi dengan kotak peralatan di lapisan yang tidak menyajikan antarmuka tunggal, minimal, dan koheren ke lapisan lain melainkan antarmuka yang luas dengan banyak konstituen yang diakses sedikit demi sedikit oleh konstituen yang sesuai dari lapisan konsumen.
Karakteristik khas dari organisasi berdasarkan lapisan adalah bahwa sambungan logis lebih kuat di dalam komponen logis yang menjangkau seluruh lapisan daripada di dalam lapisan itu sendiri. Mode kegagalan yang paling umum dari strategi ini adalah bahwa sebagian besar perubahan memerlukan file yang menyentuh di semua lapisan, pada dasarnya definisi buku teks tentang kopling ketat.
Di bawah skenario ini, ketergantungan intra-komponen logis berakhir seperti paku jelek yang didorong melalui lapisan Anda yang seharusnya dipisahkan, menariknya menjadi satu seringkali sangat kompleks unit.
Organisasi dengan lapisan harus digunakan dengan hati-hati karena sering meningkatkan kompleksitas sistem total daripada membantu mengendalikannya tetapi ada kasus di mana manfaat yang diberikannya lebih besar daripada kelemahan ini. Dalam kasus tersebut, sering kali lebih baik untuk memisahkan ketergantungan lapisan Anda ke satu tempat dalam kode konsumen Anda daripada memiliki sulurnya menjangkau seluruh basis kode:
Jangan biarkan referensi ke file sumber daya bahasa menyusup ke seluruh basis kode Anda, melainkan petakan semua hasil dan kesalahan dari komponen internal Anda ke pesan sumber daya bahasa di satu tempat dekat lapisan presentasi.
Jangan gunakan objek nilai yang dihasilkan dari skema JSON Anda di luar lapisan layanan Anda, terjemahkan ke objek domain yang tepat dan panggil secepat mungkin.
Menurut Jenis
Organization by kind adalah strategi yang mencoba menertibkan unit kode yang terlalu kompleks dengan membuang bagian-bagiannya ke dalam ember berdasarkan jenis kelas (atau antarmuka) yang dianggap. Dalam melakukan ini ia mengabaikan ketergantungan dan hubungan konseptual dan biasanya menghasilkan paket dengan nama seperti pengecualian , antarmuka , manajer , pembantu , atau entitas .
Organisasi menurut jenisnya berbeda dari organisasi menurut kotak alat dalam hal ini menghilangkan kepura-puraan bahwa kelas-kelas dalam suatu paket saling melengkapi, dapat dipertukarkan, dan/atau membentuk segala jenis perpustakaan yang masuk akal ketika disatukan. Tak seorang pun yang saya tahu menganjurkan menggunakan strategi ini untuk mengatur kode ke dalam kelas atau proyek yang terpisah ( “inilah kelas dengan semua anggota string” atau “inilah proyek di mana kami menempatkan semua pengecualian kami” ).
Saya menganggap pengorganisasian kode berdasarkan jenis berbahaya karena menyembunyikan masalah sebenarnya dari kode kompleks dan dengan demikian membuat pengembang merasa bahwa mereka telah memperbaikinya sementara kompleksitas keseluruhan tetap sama. Contoh di atas terlihat rapi dengan segala sesuatu yang dimasukkan ke dalam paket berukuran gigitan tetapi kebanyakan setiap perubahan membutuhkan menyentuh setiap paket, yang berarti bahwa paket-paket tersebut sebenarnya digabungkan dengan erat. Masalah besar lainnya dengan strategi ini adalah bahwa jika diambil secara ekstrem, setiap kelas harus memiliki jenis yang jelas. Saya telah melihat seluruh basis kode warp ini karena semua jenis hal aneh dibuat dan ditunjuk sebagai Manajer atau Pembantu hanya untuk masuk ke dalam beberapa paket.
Saya menganggap organisasi berdasarkan jenis kode bau tetapi dalam pengalaman saya dari proyek komersial terutama di Jawa dan C# itu cukup umum. Saya percaya bahwa ini terjadi karena tampaknya menyediakan cara mudah untuk mempartisi paket besar dan kebanyakan orang tidak menyadari bahwa ukuran paket bukanlah masalah utama, jumlah bagian yang saling bergantung adalah.
