Apakah mengikuti SOLID mengarah pada penulisan kerangka kerja di atas tumpukan teknologi?


70

Saya suka SOLID, dan saya mencoba yang terbaik untuk menggunakannya dan menerapkannya ketika saya sedang berkembang. Tapi saya merasa seolah-olah pendekatan SOLID mengubah kode Anda menjadi kode 'kerangka kerja' - yaitu kode yang akan Anda desain jika Anda membuat kerangka kerja atau pustaka untuk digunakan pengembang lain.

Saya secara umum telah mempraktekkan 2 mode pemrograman - membuat kurang lebih persis apa yang diminta melalui persyaratan dan KISS (pemrograman tipikal), atau membuat logika yang sangat umum dan dapat digunakan kembali, layanan, dll yang memberikan fleksibilitas yang mungkin dibutuhkan pengembang lain (kerangka pemrograman) .

Jika pengguna benar-benar hanya ingin aplikasi untuk melakukan hal-hal x dan y, masuk akal untuk mengikuti SOLID dan menambahkan sejumlah besar titik masuk abstraksi, ketika Anda bahkan tidak tahu apakah itu bahkan masalah yang valid untuk memulai dengan? Jika Anda menambahkan titik entri abstraksi ini, apakah Anda benar-benar memenuhi persyaratan pengguna, atau apakah Anda membuat kerangka kerja di atas kerangka kerja dan tumpukan teknologi yang ada untuk membuat penambahan di masa mendatang lebih mudah? Dalam hal apa Anda melayani kepentingan pelanggan, atau pengembang?

Ini adalah sesuatu yang tampaknya umum di dunia Java Enterprise, di mana rasanya seolah-olah Anda sedang merancang kerangka kerja Anda sendiri di atas J2EE atau Spring sehingga itu adalah UX yang lebih baik untuk pengembang, daripada berfokus pada UX untuk pengguna?


12
Masalah dengan sebagian besar aturan pemrograman pendek adalah bahwa mereka tunduk pada interpretasi, kasus tepi, dan kadang-kadang definisi kata-kata dalam aturan tersebut tidak jelas pada pemeriksaan lebih dekat. Mereka pada dasarnya dapat berarti berbagai hal bagi orang yang berbeda. Memiliki beberapa pragmatisme non-ideologis biasanya memungkinkan seseorang untuk membuat keputusan yang lebih bijaksana.
Mark Rogers

1
Anda membuatnya terdengar seperti mengikuti prinsip-prinsip SOLID entah bagaimana menyiratkan investasi besar, banyak pekerjaan ekstra. Tidak, itu praktis gratis. Dan itu kemungkinan akan menghemat investasi besar Anda atau orang lain di masa depan karena membuat kode Anda lebih mudah untuk dipertahankan dan diperluas. Anda terus mengajukan pertanyaan seperti "haruskah kita melakukan pekerjaan rumah atau membuat pelanggan senang?" Ini bukan trade off.
Martin Maat

1
@ MartinMaat Saya berpikir bahwa bentuk SOLID yang lebih ekstrim menyiratkan investasi besar. Yaitu. Perangkat lunak perusahaan. Di luar perangkat lunak perusahaan, Anda akan memiliki sedikit alasan untuk mengabstraksikan ORM, tumpukan teknologi, atau basis data Anda karena ada kemungkinan besar Anda akan tetap menggunakan tumpukan yang Anda pilih. Dalam arti yang sama, dengan mengikat diri Anda pada kerangka kerja tertentu, database, atau ORM, Anda melanggar prinsip SOLID karena Anda digabungkan ke tumpukan Anda. Tingkat fleksibilitas dari SOLID tidak diperlukan di sebagian besar pekerjaan.
Igneous01


1
Mengubah sebagian besar kode menjadi sesuatu seperti kerangka kerja sama sekali tidak terdengar mengerikan. Itu hanya menjadi mengerikan jika menjadi over-engineered. Tetapi kerangka kerja bisa minimal dan dikemukakan pendapat. Saya tidak yakin apakah ini akan menjadi konsekuensi yang tidak terhindarkan dari mengikuti SOLID tetapi itu jelas merupakan konsekuensi yang mungkin dan yang, saya pikir, Anda harus merangkul.
Konrad Rudolph

Jawaban:


84

Pengamatan Anda benar, prinsip-prinsip SOLID adalah IMHO dibuat dengan pustaka yang dapat digunakan kembali atau kode kerangka kerja dalam pikiran. Ketika Anda hanya mengikuti semuanya secara membabi buta, tanpa bertanya apakah itu masuk akal atau tidak, Anda berisiko untuk membuat generalisasi yang berlebihan dan menginvestasikan lebih banyak upaya ke dalam sistem Anda daripada yang mungkin diperlukan.

Ini adalah trade-off, dan perlu beberapa pengalaman untuk membuat keputusan yang tepat tentang kapan harus digeneralisasi dan kapan tidak. Pendekatan yang mungkin untuk ini adalah dengan berpegang pada prinsip YAGNI - jangan membuat kode Anda SOLID "untuk berjaga-jaga" - atau, untuk menggunakan kata-kata Anda: jangan

memberikan fleksibilitas yang mungkin dibutuhkan pengembang lain

alih-alih, berikan fleksibilitas yang sebenarnya dibutuhkan pengembang lain segera setelah mereka membutuhkannya , tetapi tidak lebih awal.

Jadi, setiap kali Anda memiliki satu fungsi atau kelas dalam kode Anda, Anda tidak yakin apakah itu dapat digunakan kembali, jangan memasukkannya ke dalam kerangka kerja Anda sekarang. Tunggu hingga Anda memiliki kasing untuk reusage dan refactor menjadi "SOLID cukup untuk kasing itu". Jangan menerapkan lebih banyak konfigurabilitas (mengikuti OCP), atau titik masuk abstraksi (menggunakan DIP) ke dalam kelas yang Anda perlukan untuk kasing ulang yang sebenarnya. Tambahkan fleksibilitas berikutnya ketika persyaratan reusage berikutnya benar-benar ada.

Tentu saja, cara kerja ini akan selalu membutuhkan sejumlah refactoring pada basis kode kerja yang ada. Itulah mengapa tes otomatis penting di sini. Jadi, membuat kode Anda SOLID sejak awal hingga dapat diuji unitnya bukan merupakan pemborosan waktu, dan melakukannya tidak bertentangan dengan YAGNI. Tes otomatis adalah kasus yang valid untuk "penggunaan kembali kode", karena kode yang dipertaruhkan digunakan dari kode produksi serta dari tes. Namun perlu diingat, tambahkan saja fleksibilitas yang sebenarnya Anda butuhkan untuk membuat tes bekerja, tidak kurang, tidak lebih.

Ini sebenarnya kebijaksanaan lama. Dahulu sebelum istilah SOLID menjadi populer, seseorang mengatakan kepada saya sebelum kita mencoba menulis kode yang dapat digunakan kembali , kita harus menulis kode yang dapat digunakan . Dan saya masih berpikir ini adalah rekomendasi yang bagus.


23
Poin tambahan pertentangan: Tunggu sampai Anda memiliki 3 kasus penggunaan di mana Anda melihat logika yang sama sebelum refactoring kode Anda untuk digunakan kembali. Jika Anda memulai refactoring dengan 2 buah, mudah berakhir dalam situasi di mana perubahan persyaratan atau penggunaan baru berakhir dengan melanggar abstraksi yang Anda buat. Juga menjaga refactor terbatas pada hal-hal dengan kasus penggunaan yang sama: 2 komponen mungkin memiliki kode yang sama tetapi melakukan hal-hal yang sama sekali berbeda, dan jika Anda menggabungkan komponen-komponen itu, Anda akhirnya menautkan logika itu, yang dapat menyebabkan masalah di kemudian hari.
Nzall

8
Saya umumnya setuju dengan ini, tetapi merasa seperti itu terlalu fokus pada aplikasi "satu kali": Anda menulis kode, itu berfungsi, baik. Namun, ada banyak aplikasi dengan "dukungan lama". Anda dapat menulis beberapa kode dan 2 tahun kemudian, persyaratan bisnis berubah sehingga Anda harus menyesuaikan kode tersebut. Pada saat itu, banyak kode lain mungkin bergantung padanya - dalam hal ini, prinsip SOLID akan membuat perubahan lebih mudah.
R. Schmitz

3
"Sebelum kita mencoba menulis kode yang dapat digunakan kembali, kita harus menulis kode yang dapat digunakan" - Sangat bijaksana!
Graham

10
Mungkin perlu dicatat bahwa menunggu sampai Anda memiliki case-use yang sebenarnya akan membuat kode SOLID Anda lebih baik , karena bekerja dalam hipotesis sangat sulit dan Anda mungkin salah menebak apa kebutuhan masa depan. Proyek kami memiliki sejumlah kasus di mana segala sesuatunya dirancang untuk menjadi SOLID dan fleksibel untuk kebutuhan di masa depan ... kecuali kebutuhan di masa depan ternyata merupakan hal yang tidak dipikirkan oleh siapa pun pada saat itu, jadi kami berdua perlu memperbaiki dan memiliki fleksibilitas ekstra yang kami miliki. masih tidak perlu — yang harus dipertahankan dalam menghadapi refactoring, atau dihilangkan.
KRyan

2
juga biasanya Anda masih perlu menulis kode yang dapat diuji, yang biasanya berarti memiliki lapisan abstraksi pertama agar dapat beralih dari implementasi konkret ke pengujian.
Walfrat

49

Dari pengalaman saya, saat menulis aplikasi, Anda memiliki tiga pilihan:

  1. Tulis kode hanya untuk memenuhi persyaratan,
  2. Tulis kode umum yang mengantisipasi persyaratan di masa depan, serta memenuhi persyaratan saat ini,
  3. Tulis kode yang hanya memenuhi persyaratan saat ini, tetapi dengan cara yang mudah diubah nanti untuk memenuhi kebutuhan lain.

Dalam kasus pertama, biasanya berakhir dengan kode berpasangan ketat yang tidak memiliki tes unit. Tentu itu cepat untuk ditulis, tetapi sulit untuk diuji. Dan sakit kerajaan yang tepat untuk berubah nanti ketika persyaratan berubah.

Dalam kasus kedua, sejumlah besar waktu dihabiskan untuk mengantisipasi kebutuhan masa depan. Dan terlalu sering persyaratan yang diantisipasi di masa depan tidak pernah terwujud. Ini sepertinya skenario yang Anda gambarkan. Sebagian besar waktu hanya buang-buang waktu dan menghasilkan kode rumit yang tidak perlu yang masih sulit diubah ketika persyaratan yang tidak diantisipasi untuk muncul.

Kasus terakhir adalah yang saya tuju dalam pandangan saya. Gunakan TDD atau teknik serupa untuk menguji kode saat Anda pergi dan Anda akan berakhir dengan kode yang digabungkan secara longgar, itu mudah untuk dimodifikasi namun masih cepat untuk menulis. Dan masalahnya adalah, dengan melakukan ini, Anda secara alami mengikuti banyak prinsip SOLID: kelas dan fungsi kecil; antarmuka dan dependensi yang disuntikkan. Dan Nyonya Liskov pada umumnya tetap senang juga karena kelas-kelas sederhana dengan tanggung jawab tunggal jarang melanggar prinsip substitusi.

Satu-satunya aspek SOLID yang tidak benar-benar berlaku di sini adalah prinsip terbuka / tertutup. Untuk perpustakaan dan kerangka kerja, ini penting. Untuk aplikasi mandiri, tidak terlalu banyak. Benar-benar ini adalah kasus penulisan kode yang mengikuti " SLID ": mudah untuk menulis (dan membaca), mudah untuk diuji dan mudah untuk dipelihara.


salah satu jawaban favorit saya di situs ini!
TheCatWhisperer

Saya tidak yakin bagaimana Anda menyimpulkan bahwa 1) lebih sulit untuk diuji daripada 3). Lebih sulit untuk melakukan perubahan, tentu, tetapi mengapa Anda tidak bisa menguji? Jika ada, perangkat lunak satu pikiran lebih mudah untuk menguji terhadap persyaratan daripada yang lebih umum.
Mr Lister

@MrLister Keduanya berjalan beriringan, 1. lebih sulit untuk diuji daripada 3. karena definisi menyiratkan itu tidak ditulis "dengan cara yang mudah diubah nanti untuk memenuhi kebutuhan lain."
Mark Booth

1
+0; IMVHO Anda salah mengartikan (meskipun dengan cara yang umum) cara 'O' (buka-tutup) bekerja. Lihat mis. Codeblog.jonskeet.uk/2013/03/15/… - bahkan dalam basis kode kecil, ini lebih tentang memiliki unit kode mandiri (misalnya kelas, modul, paket, apa pun), yang dapat diuji secara terpisah dan ditambahkan Saya dihapus saat dibutuhkan. Salah satu contohnya adalah paket metode utilitas - terlepas dari cara Anda membundelnya, mereka harus 'ditutup', yaitu mandiri, dan 'terbuka', yaitu dapat diperpanjang dengan beberapa cara.
vaxquis

BTW, bahkan Paman Bob seperti itu pada satu titik: “Apa [buka-tutup] artinya adalah Anda harus berusaha keras untuk mendapatkan kode Anda ke posisi sehingga, ketika perilaku berubah dengan cara yang diharapkan, Anda tidak perlu melakukan sweeping perubahan ke semua modul sistem. Idealnya, Anda dapat menambahkan perilaku baru dengan menambahkan kode baru, dan mengubah sedikit atau tidak ada kode lama. " <- ini jelas berlaku bahkan untuk aplikasi kecil, jika mereka dimaksudkan untuk dimodifikasi atau diperbaiki (dan, IMVHO, itu biasanya terjadi, khususnya ketika menyangkut perbaikan terkekeh )
vaxquis

8

Perspektif yang Anda miliki dapat dipengaruhi oleh pengalaman pribadi. Ini adalah kemiringan yang licin dari fakta yang secara individual benar, tetapi kesimpulan yang dihasilkan tidak, meskipun tampak benar pada pandangan pertama.

  • Kerangka dalam lingkup lebih besar dari proyek-proyek kecil.
  • Praktik buruk secara signifikan lebih sulit untuk ditangani dalam basis kode yang lebih besar.
  • Membangun kerangka kerja (rata-rata) membutuhkan pengembang yang lebih terampil daripada membangun proyek kecil.
  • Pengembang yang lebih baik mengikuti praktik yang baik (SOLID) lebih lanjut.
  • Akibatnya, kerangka kerja memiliki kebutuhan yang lebih tinggi untuk praktik yang baik dan cenderung dibangun oleh pengembang yang lebih berpengalaman dengan praktik yang baik.

Ini berarti bahwa ketika Anda berinteraksi dengan kerangka kerja dan pustaka yang lebih kecil, kode praktik yang baik yang akan berinteraksi dengan Anda akan lebih umum ditemukan dalam kerangka kerja yang lebih besar.

Kekeliruan ini sangat umum, misalnya setiap dokter yang saya rawat sombong. Karena itu saya menyimpulkan bahwa semua dokter sombong. Kesalahan-kesalahan ini selalu menderita membuat selimut inferensi berdasarkan pengalaman pribadi.

Dalam kasus Anda, mungkin Anda sebagian besar mengalami praktik yang baik dalam kerangka kerja yang lebih besar dan tidak di perpustakaan yang lebih kecil. Pengamatan pribadi Anda tidak salah, tetapi merupakan bukti anekdotal dan tidak berlaku secara universal.


2 mode pemrograman - membuat lebih atau kurang persis apa yang diminta melalui persyaratan dan KISS (pemrograman tipikal), atau membuat logika, layanan, dll yang sangat umum dan dapat digunakan kembali, yang memberikan fleksibilitas yang mungkin dibutuhkan pengembang lain (kerangka pemrograman)

Anda agak mengkonfirmasi ini di sini. Pikirkan apa itu kerangka kerja. Ini bukan aplikasi. Ini adalah "template" umum yang dapat digunakan orang lain untuk membuat semua jenis aplikasi. Secara logis, itu berarti bahwa suatu kerangka kerja dibangun dalam logika yang jauh lebih abstrak untuk dapat digunakan oleh semua orang.

Pembuat kerangka tidak dapat mengambil jalan pintas, karena mereka bahkan tidak tahu apa persyaratan dari aplikasi selanjutnya. Membangun kerangka kerja secara inheren memberi insentif kepada mereka untuk membuat kode mereka dapat digunakan untuk orang lain.

Pembuat aplikasi, bagaimanapun, memiliki kemampuan untuk berkompromi pada efisiensi logis karena mereka berfokus pada memberikan produk. Tujuan utama mereka bukanlah cara kerja kode melainkan pengalaman pengguna.

Untuk suatu kerangka kerja, pengguna akhir adalah pengembang lain, yang akan berinteraksi dengan kode Anda. Kualitas kode Anda penting bagi pengguna akhir Anda.
Untuk aplikasi, pengguna akhir adalah non-pengembang, yang tidak akan berinteraksi dengan kode Anda. Kualitas kode Anda tidak penting bagi mereka.

Inilah sebabnya mengapa arsitek dari tim pengembangan sering bertindak sebagai penegak praktik yang baik. Mereka adalah satu langkah dihapus dari pengiriman produk, yang berarti mereka cenderung melihat kode secara objektif, daripada berfokus pada pengiriman aplikasi itu sendiri.


Jika Anda menambahkan titik entri abstraksi ini, apakah Anda benar-benar memenuhi persyaratan pengguna, atau apakah Anda membuat kerangka kerja di atas kerangka kerja dan tumpukan teknologi yang ada untuk membuat penambahan di masa mendatang lebih mudah? Dalam hal apa Anda melayani kepentingan pelanggan, atau pengembang?

Ini adalah poin yang menarik, dan ini (menurut pengalaman saya) adalah alasan utama mengapa orang masih mencoba untuk membenarkan untuk menghindari praktik yang baik.

Untuk meringkas poin-poin di bawah ini: Melewati praktik yang baik hanya dapat dibenarkan jika persyaratan Anda (seperti yang diketahui saat ini) tidak dapat diubah, dan tidak akan pernah ada perubahan / penambahan pada basis kode. Peringatan spoiler: Itu jarang terjadi.
Misalnya, ketika saya menulis aplikasi konsol 5 menit untuk memproses file tertentu, saya tidak menggunakan praktik yang baik. Karena saya hanya akan menggunakan aplikasi hari ini, dan itu tidak perlu diperbarui di masa depan (akan lebih mudah untuk menulis aplikasi yang berbeda jika saya membutuhkannya lagi).

Katakanlah Anda dapat membuat aplikasi dengan kurang hati-hati dalam 4 minggu, dan Anda dapat membuatnya dengan benar dalam 6 minggu. Pada pandangan pertama, bangunan yang jelek sepertinya lebih baik. Pelanggan mendapatkan aplikasi mereka lebih cepat, dan perusahaan harus menghabiskan lebih sedikit waktu untuk upah pengembang. Menang / menang, kan?

Namun, ini adalah keputusan yang dibuat tanpa berpikir ke depan. Karena kualitas basis kode, membuat perubahan besar untuk yang dibangun dengan shoddily akan memakan waktu 2 minggu, sementara membuat perubahan yang sama dengan yang dibangun dengan benar membutuhkan waktu 1 minggu. Mungkin ada banyak dari perubahan ini yang muncul di masa depan.

Selain itu, ada kecenderungan perubahan yang tidak terduga membutuhkan lebih banyak pekerjaan daripada yang Anda bayangkan dalam basis kode yang dibangun dengan buruk, sehingga kemungkinan mendorong waktu pengembangan Anda menjadi tiga minggu, bukannya dua.

Dan kemudian ada juga kecenderungan untuk membuang waktu berburu serangga. Ini sering terjadi dalam proyek-proyek di mana penebangan telah diabaikan karena keterbatasan waktu atau semata-mata karena tidak mau menerapkannya karena Anda tanpa sadar bekerja dengan asumsi bahwa produk akhir akan bekerja seperti yang diharapkan.

Bahkan tidak perlu menjadi pembaruan besar. Di perusahaan saya saat ini, saya telah melihat beberapa proyek yang dibangun dengan cepat dan kotor, dan ketika bug / perubahan terkecil perlu dilakukan karena miskomunikasi dalam persyaratan, yang mengarah pada reaksi berantai tentang perlunya refactor modul demi modul . Beberapa proyek ini akhirnya runtuh (dan meninggalkan kekacauan yang tidak dapat dipertahankan) bahkan sebelum mereka merilis versi pertama mereka.

Keputusan pintasan (pemrograman cepat dan kotor) hanya bermanfaat jika Anda dapat secara meyakinkan menjamin bahwa persyaratannya benar dan tidak perlu diubah. Dalam pengalaman saya, saya tidak pernah menemukan proyek di mana itu benar.

Menginvestasikan waktu ekstra dalam praktik yang baik adalah berinvestasi di masa depan. Bug dan perubahan di masa mendatang akan jauh lebih mudah ketika basis kode yang ada dibangun berdasarkan praktik yang baik. Itu sudah akan membayar dividen setelah hanya dua atau tiga perubahan dilakukan.


1
Ini adalah jawaban yang baik, tetapi saya harus mengklarifikasi bahwa saya tidak mengatakan kita meninggalkan praktik yang baik, tetapi tingkat 'praktik yang baik' apa yang kita kejar? Apakah praktik yang baik untuk mengabstraksikan ORM Anda di setiap proyek karena Anda 'mungkin' perlu menukar itu dengan yang lain nanti? Saya tidak berpikir begitu, ada beberapa tingkat kopling yang saya bersedia terima (mis. Saya terikat dengan kerangka kerja, bahasa, ORM, database yang dipilih). Jika kita mengikuti SOLID ke tingkat ekstremisnya, apakah kita benar-benar hanya menerapkan kerangka kerja kita sendiri di atas tumpukan yang dipilih?
Igneous01

Anda menyangkal pengalaman OP sebagai "fallacy". Tidak konstruktif.
max630

@ max630 Saya tidak menyangkalnya. Saya menghabiskan sebagian besar jawaban untuk menjelaskan mengapa pengamatan OP valid.
Flater

1
@ Igneous01 SOLID bukan kerangka. SOLID adalah abstraksi, yang lebih sering ditemui dalam suatu kerangka kerja. Ketika menerapkan segala jenis abstraksi (termasuk SOLID), selalu ada garis kewajaran. Anda tidak bisa hanya abstrak demi abstraksi, Anda akan menghabiskan waktu lama menghasilkan kode yang terlalu umum sehingga sulit untuk diikuti. Hanya abstrak apa yang Anda duga wajar akan berguna bagi Anda di masa depan. Namun, jangan jatuh ke dalam perangkap dengan asumsi Anda terikat misalnya server database Anda saat ini. Anda tidak pernah tahu database baru apa yang akan dirilis besok.
Flater

@ Igneous01 Dengan kata lain, Anda memiliki ide yang tepat dengan tidak ingin mengabstraksikan segala sesuatu, tetapi saya mendapatkan perasaan bahwa Anda condong sedikit terlalu jauh ke arah itu. Sangat umum bagi pengembang untuk berasumsi bahwa persyaratan saat ini ditetapkan, dan untuk kemudian membuat keputusan arsitektur berdasarkan asumsi (angan-angan).
Flater

7

Bagaimana SOLID mengubah kode sederhana menjadi kode kerangka kerja? Saya bukan stan untuk SOLID dengan cara apa pun tetapi benar-benar tidak jelas apa yang Anda maksud di sini.

  • KISS esensi dari S perapian di tungku Prinsip Tanggung Jawab.
  • Tidak ada apa pun dalam O pena / Prinsip Tertutup (setidaknya seperti yang saya pahami — lihat Jon Skeet ) yang bertentangan dengan penulisan kode untuk melakukan satu hal dengan baik. (Faktanya, semakin fokus kode ini, semakin penting bagian "tertutup" jadinya.)
  • The L iskov Pergantian Prinsip tidak mengatakan Anda harus membiarkan orang subclass kelas Anda. Dikatakan bahwa jika Anda subkelas kelas Anda, subkelas Anda harus memenuhi kontrak superclasses mereka. Itu hanya desain OO yang bagus. (Dan jika Anda tidak memiliki subclass apa pun, itu tidak berlaku.)
  • KISS juga esensi dari saya nterface Pemisahan Prinsip.
  • The D ependency Pembalikan Prinsip adalah satu-satunya yang saya dapat melihat dari jarak jauh menerapkan, tapi saya pikir itu secara luas disalahpahami dan berlebihan. Itu tidak berarti Anda harus menyuntikkan semuanya dengan Guice atau Spring. Ini hanya berarti bahwa Anda harus abstrak jika perlu dan tidak bergantung pada detail implementasi.

Saya akui saya tidak berpikir dalam istilah SOLID sendiri, karena saya datang melalui sekolah pemrograman Gang of Four dan Josh Bloch , bukan sekolah Bob Martin. Tapi saya benar-benar berpikir bahwa jika Anda berpikir "SOLID" = "menambahkan lebih banyak lapisan ke tumpukan teknologi", Anda salah membaca.


PS Jangan menjual keuntungan dari "UX yang lebih baik untuk pengembang" singkat. Kode menghabiskan sebagian besar hidupnya dalam pemeliharaan. Pengembang adalah Anda .


1
Mengenai SRP - orang bisa berpendapat bahwa kelas apa pun dengan konstruktor melanggar SRP, karena Anda dapat melepaskan tanggung jawab itu ke pabrik. Mengenai OCP - ini benar-benar masalah tingkat kerangka kerja, karena begitu Anda menerbitkan antarmuka untuk konsumsi untuk penggunaan luar, Anda tidak dapat memodifikasinya. Jika antarmuka hanya digunakan di dalam proyek Anda, maka dimungkinkan untuk mengubah kontrak, karena Anda memiliki kekuatan untuk mengubah kontrak dalam kode Anda sendiri. Mengenai ISP - orang bisa berpendapat bahwa antarmuka harus didefinisikan untuk setiap tindakan individu (sehingga melestarikan SRP), dan menyangkut pengguna luar.
Igneous01

3
1) orang bisa, tetapi saya ragu ada orang yang layak mendengarkan. 2) Anda mungkin terkejut betapa cepat satu proyek dapat tumbuh ke ukuran yang secara bebas memodifikasi antarmuka internal menjadi ide yang buruk. 3) lihat 1) dan 2). Cukuplah untuk mengatakan saya pikir Anda terlalu banyak membaca ketiga prinsip ini. Tetapi komentar sebenarnya bukan tempat untuk membahas argumen ini; Saya sarankan Anda mengajukan masing-masing sebagai pertanyaan terpisah dan melihat jawaban seperti apa yang Anda dapatkan.
David Moles

4
@ Igneous01 Menggunakan logika itu, Anda mungkin juga meninggalkan getter dan setter, karena Anda dapat membuat kelas terpisah untuk setiap setter variabel dan satu untuk setiap pengambil. IE: class A{ int X; int Y; } class A_setX{ f(A a, int N) { a.X = N; }} class A_getX{ int f(A a) { return X; }} class A_setY ... etc.Saya pikir Anda melihatnya dari sudut pandang yang terlalu meta dengan klaim pabrik Anda. Inisialisasi bukan merupakan aspek dari masalah domain.
Aaron

@ Harun ini. Orang dapat menggunakan SOLID untuk membuat argumen buruk, tetapi itu tidak berarti melakukan hal-hal buruk = "mengikuti SOLID".
David Moles
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.