Intern Wellcode.io - Clean Code; Apa itu Class?

Jadi software engineer bukan berarti gabisa sukses berbisnis loh, join dulu ke pinterusaha.ai

Kelas

dengan Jeff Langr Sejauh ini kami telah membahas bagaimana menulis baris dan blok kode dengan baik clean code. Kita menyelidiki komposisi fungsi yang tepat dan bagaimana mereka saling terkait. Sekarang kita membahas tentang kelas bersih.

Organisasi Kelas

Mengikuti konvensi Java standar, sebuah kelas harus dimulai dengan daftar variabel. Konstanta statis publik, jika ada, harus didahulukan. Kemudian variabel statis pribadi, diikuti oleh variabel instance pribadi. Jarang ada alasan bagus untuk memiliki variabel 

Publik.

Fungsi publik harus mengikuti daftar variabel. Kami suka menempatkan utilitas pribadi dipanggil oleh fungsi publik tepat setelah fungsi publik itu sendiri. Ini mengikuti stepdownaturan dan bantu program membaca seperti artikel koran.

Enkapsulasi

Kami ingin menjaga variabel dan fungsi utilitas kami tetap pribadi, tetapi kami tidak fanatik tentang hal itu. Terkadang kita perlu membuat variabel atau fungsi utilitas terlindungi agar bisa diakses dengan tes. Bagi kami aturan tes itu jika, tes dalam paket yang sama perlu memanggil fungsi atau mengakses variabel, kami akan membuatnya terlindungi atau cakupan paket. Namun, pertama-tama kami akan mencari cara untuk menjaga privasi. Melonggarkan enkapsulasi selalu menjadi pilihan terakhir.

The Single Responsibility Principle 

The Single Responsibility Principle (SRP) menyatakan bahwa kelas atau modul harus memiliki satu,dan hanya satu alasan untuk berubah. Prinsip ini memberi kita definisi dari tanggung jawab,dan pedoman untuk ukuran kelas. Kelas harus memiliki satu tanggung jawab — satu alasan untuk perubahan.

Pertama, ia melacak informasi versi yang tampaknya perlu diperbarui setiap kali

perangkat lunak dikirimkan. Kedua, ia mengelola komponen Java Swing (turunan dari JFrame, representasi Swing dari jendela GUI tingkat atas). Tidak diragukan lagi kami akan menginginkannya perbarui nomor versi jika kami mengubah salah satu kode Swing, tetapi sebaliknya tidak selalu benar: Kami dapat mengubah informasi versi berdasarkan perubahan pada kode lain di sistem.

SRP adalah salah satu konsep yang lebih penting dalam desain OO. Itu juga salah satu yang lebih sederhana konsep untuk dipahami dan dipatuhi. Namun anehnya, SRP merupakan prinsip desain kelas yang paling banyak disalah gunakan. Kami secara teratur menghadapi kelas yang melakukan terlalu banyak hal. Mengapa? Membuat perangkat lunak berfungsi dan membersihkan perangkat lunak adalah dua kegiatan yang sangat berbeda.

Sebagian besar dari kita memiliki ruang terbatas di kepala kita, jadi kita fokus pada mendapatkan kode kita untuk bekerja lebih banyak dari organisasi dan kebersihan. Ini sepenuhnya tepat. Mempertahankan pemisahan kekhawatiran sama pentingnya dalam kegiatan pemrograman kami seperti halnya dalam program kami. Masalahnya adalah bahwa terlalu banyak dari kita berpikir bahwa kita selesai begitu program kerja.

Kami gagal beralih ke masalah organisasi dan kebersihan lainnya. Kami pindah ke

Masalah selanjutnya daripada kembali dan memecah overstuffed classes menjadi units with single responsibilities. Pada saat yang sama, banyak pengembang takut bahwa tujuan kecil kelas membuatnya lebih sulit untuk memahami gambaran yang lebih besar. Mereka khawatir itu harus bernavigasi dari satu kelas ke kelas lain untuk mencari tahu bagaimana hasil pekerjaan yang lebih besar. Namun, sistem dengan banyak kelas kecil tidak memiliki bagian yang bergerak selain sistem dengan beberapa kelas besar. Ada banyak hal yang harus dipelajari dalam sistem dengan sedikit kelas. 

Jadi pertanyaannya adalah: Apakah Anda ingin alat Anda diorganisasikan ke dalam kotak alat dengan banyak laci kecil masing-masing berisi komponen yang terdefinisi dengan baik dan berlabel baik? Atau kamu mau beberapa laci tempat Anda membuang semuanya? Setiap sistem yang cukup besar akan mengandung banyak logika dan kompleksitas. Tujuan utama dalam mengelola kompleksitas tersebut adalah untuk mengaturnya sehingga pengembang tahu di mana mencari untuk menemukan hal-hal dan hanya perlu memahami kompleksitas yang secara langsung terpengaruh diberikan waktu. Sebaliknya, sistem dengan kelas multiguna yang lebih besar selalu menghambat kita bersikeras kami mengarungi banyak hal yang tidak perlu kita ketahui sekarang. Untuk menyatakan kembali poin-poin sebelumnya untuk penekanan: Kami ingin sistem kami terdiri dari banyak kelas kecil, tidak sedikit yang besar. Setiap kelas kecil merangkum satu tanggung jawab, memiliki satu alasan untuk berubah, dan berkolaborasi dengan beberapa orang lain untuk mencapai hal tersebut perilaku sistem yang diinginkan.

Mengisolasi dari Perubahan

Kebutuhan akan berubah, oleh karena itu kode akan berubah. Kami belajar di OO bahwa ada kelas konkret, yang berisi detail implementasi (kode), dan kela abstrak, yang hanya mewakili konsep. Kelas klien tergantung pada detail nyata yang berisiko kapan detail-detail itu berubah. Kami dapat memperkenalkan antarmuka dan kelas abstrak untuk membantu mengisolasikannya dampak dari detail tersebut.Ketergantungan pada detail nyata menciptakan tantangan untuk menguji sistem kami. Jika kita membangun kelas Portofolio dan itu tergantung pada TokyoStockExchange API eksternal untuk menurunkan nilai portofolio, uji kasus kami dipengaruhi oleh volatilitas pencarian tersebut. Sulit untuk menulis ujian ketika kami mendapat jawaban berbeda setiap lima menit!

Jika suatu sistem dipisahkan cukup untuk diuji dengan cara ini, itu juga akan lebih fleksibel dan mempromosikan lebih banyak penggunaan kembali. Tidak adanya kopling berarti elemen-elemen sistem kami lebih terisolasi satu sama lain dan dari perubahan. Isolasi ini memudahkan untuk memahami setiap elemen sistem.

by: nrlsyiffa

Wellcode.io Team

Leading high-tech Indonesia Startup Digital - which serves the community with revolutionary products, system development, and information technology infrastructure