Latar belakang: memahami prinsip-prinsip SOLID

Kami akan memberi tahu Anda siapa yang menemukannya dan apa itu. Mari kita juga berbicara tentang kritik terhadap pendekatan ini - tentang mengapa beberapa pengembang menolak untuk mengikuti metodologi SOLID.





Foto - nesa - Unsplash



Akronim



SOLID - menunjukkan lima prinsip pertama dari pemrograman berorientasi objek:





Jika Anda mengikuti ini dan menyusun kelas dan fungsi Anda sehingga prinsip SOLID menjadi benar, Anda cenderung mendapatkan kode yang andal, dapat dipahami, dan mudah dipelihara. Ngomong-ngomong, ada contoh di sini untuk mengilustrasikan cara kerja setiap prinsip.



Siapa yang membawa SOLID



Seperti yang bisa Anda duga, Paman Bob- lah yang bertanggung jawab atas sebagian besar prinsip . Dia menggambarkannya secara komprehensif dalam 2000 Design Principles and Design Patterns , dan akronim SOLID kemudian disarankan oleh insinyur Michael Feathers. Jika Anda tertarik, Michael memiliki sebuah buku di mana dia memberikan nasihat tentang cara "menghidupkan kembali" sistem warisan dan tidak menjadi gila di sepanjang jalan.





Photo - Oskar Yildiz - Unsplash



SOLID memiliki misi untuk membantu mengembangkan aplikasi yang mudah dipelihara dan diperluas dari waktu ke waktu. Tetapi pedoman ini sering kali dikritik.



Untuk apa dikritik



Prinsip-prinsip ini terkadang disebut "terlalu kabur", yang membuatnya sulit untuk digunakan dalam praktik. Programmer dan penulis Joel Spolsky juga mencatat di salah satu The StackOverflow Podcast bahwa metodologi SOLID terlalu utopis dan memaksa pengembang untuk menghabiskan waktu pada kode redundan, pada kenyataannya, demi tanda centang.



Dia percaya bahwa tidak perlu mencoba sebelumnya untuk memperhitungkan semua kemungkinan skenario dan hanya memprogram, secara bertahap memperbaiki kekurangan, dan tidak bergantung pada "sistem keamanan" imajiner. Spolsky tidak meniadakan pentingnya prinsip-prinsip tersebut, tetapi menyebutnya berlebihan.



Ada pendapatbahwa kode SOLID kurang koheren dan mudah untuk diuji, tetapi sangat sulit untuk dipahami (kritik menggunakan kata "tidak dapat dipahami"). Programmer harus menulis banyak antarmuka terperinci dan kelas kecil yang lebih mengganggu dan membingungkan daripada membantu menyiapkan sistem. Pernyataan ini dibagikan oleh banyak orang yang percaya bahwa berfokus pada kesederhanaan kode sudah cukup bagi developer lain untuk mendukungnya.





Foto - Kevin Canlas - Topik



Berita Peretas Unsplash Bicaradan bahwa pilihan arsitektur, tumpukan teknologi, dan manajemen ketergantungan proyek jauh lebih penting, dan bukan prinsip dasar yang menjadi dasar penulisannya. Di sini sekali lagi mereka menunjuk pada kerumitan yang tidak perlu dimulai dengan desain sistem terintegrasi, menunjuk pada prinsip YAGNI atau " Anda tidak akan membutuhkannya ". Sampai batas tertentu, ini adalah remix lain dari pendekatan KISS klasik .



Kami harus mengakui bahwa ada banyak pernyataan yang membela SOLID. Jadi, salah satu penghuni HN mengatakan bahwa mengikuti prinsip-prinsip ini akan membantu mengganti perpustakaan bersyarat dengan cepat jika terjadi kesalahan pada tingkat abstraksi. Ini akan cukup untuk memastikan bahwa pengujian berjalan untuk implementasi baru dan hanya itu, maksimumnya adalah memeriksa dependensi untuk versi lama kelas dan, jika perlu, gunakan versi yang dimodifikasi sehingga pengujian berhasil. Maka tidak akan ada "kerumitan yang tidak perlu" dalam kode, dan mereka yang akan menanganinya nanti tidak akan menghadapi apa yang disebut sindrom penolakan perkembangan orang lain .



Penting untuk diingat bahwa prinsip SOLID hanyalah pedoman, bukan peraturan ketat. Dan akan selalu ada kasus ketika lebih baik menaatinya dan kapan mundur.






1cloud.ru:



โ€” HTTP-

,

UTF-8






:









All Articles