Pemrograman Prinsip SOLID


43

Seiring waktu saya dapat memahami dua bagian SOLID - "S" dan "O".

"O" - Saya belajar Prinsip Terbuka Terbuka dengan bantuan Pola Warisan dan Strategi.

"S" - Saya belajar prinsip Tanggung Jawab Tunggal saat mempelajari ORM (logika kegigihan diambil dari objek domain).

Dengan cara yang sama, apa wilayah / tugas terbaik untuk mempelajari bagian SOLID lainnya ("L", "I" dan "D")?

Referensi

  1. msdn - Bahaya Melanggar Prinsip SOLID dalam C #
  2. channel9 - Menerapkan Prinsip SOLID dalam .NET / C #
  3. Prinsip OOPS (Prinsip SOLID)

25
perhatikan bahwa semua ide ini adalah ide bagus, dan bersama-sama mereka sangat bagus. tetapi jika Anda menerapkannya secara dogmatis, itu akan menyebabkan lebih banyak kegagalan daripada kesuksesan.

3
OR-Mappers baik untuk pemisahan masalah, bukan prinsip tanggung jawab tunggal. Lihat posting ini programmer.stackexchange.com/questions/155628/… untuk diskusi tentang perbedaan.
Doc Brown

Contoh dunia nyata blog.gauffin.org/2012/05/...
LCJ

1
@JarrodRoberson Yap, itu sebabnya mereka secara hati-hati disebut sebagai pedoman . Juga jangan lupa prinsip-prinsip lainnya: adamjamesnaylor.com/2012/11/12/… (total 11)
Adam Naylor

2
Tautan @AdamNaylor sekarang berusia 404, sudah dipindahkan ke adamjamesnaylor.com/post/…
mattumotu

Jawaban:


54

Saya berada di sepatu Anda beberapa bulan yang lalu sampai saya menemukan artikel yang sangat membantu.

Setiap prinsip dijelaskan dengan baik dengan situasi dunia nyata yang mungkin dihadapi masing-masing pengembang perangkat lunak dalam proyek mereka. Saya memotong pendek di sini dan menunjuk ke referensi - Pengembangan Perangkat Lunak SOLID, Satu Langkah Sekaligus .

Seperti yang ditunjukkan dalam komentar, ada bacaan pdf lain yang sangat bagus - Pablo's SOLID Software Development .

Selain itu, ada beberapa buku bagus yang menggambarkan prinsip-prinsip SOLID secara lebih rinci - Buku Bagus tentang Pengembangan Perangkat Lunak SOLID .

Edit dan komentar ringkasan singkat untuk setiap prinsip:

  • "S" - Prinsip Tanggung Jawab Tunggal didorong oleh kebutuhan bisnis untuk memungkinkan perubahan. "Satu alasan untuk berubah" membantu Anda memahami konsep mana yang secara logis terpisah harus dikelompokkan bersama dengan mempertimbangkan konsep dan konteks bisnis, alih-alih konsep teknis saja. In another words, saya belajar bahwa setiap kelas harus memiliki satu tanggung jawab. Tanggung jawabnya adalah hanya menyelesaikan tugas yang ditugaskan

  • "O" - Saya belajar Prinsip Terbuka Terbuka dan mulai "lebih suka komposisi daripada warisan" dan karena itu, lebih memilih kelas yang tidak memiliki metode virtual dan mungkin disegel, tetapi bergantung pada abstraksi untuk ekstensi mereka.

  • "L" - Saya belajar Prinsip Pergantian Liskov dengan bantuan pola Repositori untuk mengelola akses data.

  • "Saya" - Saya belajar tentang Prinsip Segregasi Antarmuka dengan mempelajari bahwa klien tidak boleh dipaksa untuk mengimplementasikan antarmuka yang tidak mereka gunakan (seperti di Membership Provider di ASP.NET 2.0). Jadi antarmuka seharusnya tidak memiliki "banyak tanggung jawab"
  • "D" - Saya belajar tentang Prinsip Pembalikan Ketergantungan dan mulai membuat kode yang mudah diubah . Lebih mudah untuk berubah berarti total biaya kepemilikan yang lebih rendah dan pemeliharaan yang lebih tinggi.

Karena sumber yang bermanfaat dari CodePlex disebutkan dalam komentar, referensi dimasukkan ke SOLID sebagai contoh

masukkan deskripsi gambar di sini


3
Saya menemukan kumpulan artikel berikut ini sangat berguna: lostechies.com/wp-content/uploads/2011/03/…
Scroog1

Saya membaca seluruh artikel itu dan saya tidak dijual berdasarkan pola atau SOLID. Contohnya terlalu sederhana, tetapi ketika menjadi kompleks kompleksitas itu buatan. Saya belum menemukan OOP SOLID dunia nyata tanpa alternatif yang lebih baik.
Ayub

3
karena artikel-artikel yang hilang disebutkan di sini, ada juga solidexamples.codeplex.com ini (berdasarkan kerugiannya)
dark fader

2
Saya adalah salah satu kontributor Pablos eBook. Saya senang orang masih merasakan manfaatnya. :)
Sean Chambers

1
+1000000 jika saya bisa untuk ringkasan Anda tentang prinsip Terbuka-Tutup - semua orang salah dan berpikir ini tentang warisan
AlexFoxGill

11

(I) Segregasi nterface dan (D) versiensi Inversi dapat dipelajari melalui pengujian dan penghinaan unit. Jika kelas membuat dependensi mereka sendiri, Anda tidak dapat membuat tes unit yang baik. Jika mereka bergantung pada antarmuka yang terlalu luas (atau tidak ada antarmuka sama sekali), tidak terlalu jelas apa yang perlu diejek untuk membuat unit test Anda.


2
+1 ini sangat benar. Anda bahkan tidak harus mematuhi (imo) kadang-kadang terlalu ketat 'tes unit seharusnya hanya menguji satu hal' aturan: jika Anda tidak dapat datang dengan suite tes yang layak untuk kelas dalam beberapa menit, itu melanggar I dan D dan mungkin sisa alfabet juga
stijn

8

Prinsip Substitusi Liskov pada dasarnya tidak membiarkan Anda terlalu sering menggunakan warisan implementasi: Anda tidak boleh menggunakan warisan hanya untuk penggunaan kembali kode (ada komposisi untuk ini)! Dengan mematuhi LSP, Anda dapat yakin bahwa sebenarnya ada "hubungan-is-a" antara superclass dan subclass Anda.

Apa yang dikatakannya adalah bahwa subclass Anda harus mengimplementasikan semua metode subclass dengan cara yang mirip dengan implementasi metode di subclass. Anda tidak boleh menimpa metode dengan mengimplementasikan NOP atau mengembalikan nol ketika supertipe melempar pengecualian; dinyatakan dalam persyaratan Desain oleh Kontrak, Anda harus menghormati kontrak metode dari superclass ketika mengganti metode. Cara untuk mempertahankan diri dari melanggar prinsip ini adalah dengan tidak pernah mengganti metode yang diterapkan; bukan mengekstrak antarmuka dan mengimplementasikan antarmuka itu di kedua kelas.

Prinsip Segregasi Antarmuka , Prinsip Tanggung Jawab Tunggal dan Prinsip Coehsion Tinggi dari GRASP entah bagaimana terkait; mereka merujuk pada fakta bahwa suatu entitas harus bertanggung jawab hanya untuk satu hal sehingga hanya ada satu alasan untuk perubahan sehingga perubahan dilakukan dengan sangat mudah.

Sebenarnya dikatakan bahwa jika sebuah kelas mengimplementasikan sebuah antarmuka maka ia harus mengimplementasikan dan menggunakan semua metode antarmuka itu. Jika ada metode yang tidak diperlukan di kelas tertentu, maka antarmuka tidak baik dan harus dibagi menjadi dua antarmuka yang hanya memiliki metode yang dibutuhkan oleh kelas asli. Ini dapat dianggap dari POV, yang berhubungan dengan prinsip sebelumnya dengan fakta bahwa ia tidak membiarkan Anda membuat antarmuka besar sehingga implementasinya dapat merusak LSP.

Anda dapat melihat Pembalikan Ketergantungan dalam Pola Pabrik; di sini baik komponen tingkat tinggi (klien) dan komponen tingkat rendah (contoh individu yang akan dibuat) tergantung pada abstraksi(antarmuka). Cara untuk menerapkannya dalam arsitektur berlapis: Anda tidak harus mendefinisikan antarmuka ke lapisan di lapisan yang diimplementasikan tetapi dalam modul yang disebut. Misalnya API ke lapisan sumber data tidak boleh ditulis dalam lapisan sumber data tetapi di lapisan logika bisnis, di mana ia perlu dipanggil. Dengan cara ini, lapisan sumber data mewarisi / tergantung pada perilaku yang didefinisikan dalam logika bisnis (dengan demikian inversi) dan bukan sebaliknya (seperti yang akan terjadi pada cara yang normal). Ini memberikan fleksibilitas dalam desain, membiarkan logika bisnis bekerja tanpa perubahan kode, dengan sumber data lain yang sama sekali berbeda.


1
Penjelasan hebat tentang Liskov. :)
John Korsnes
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.