Principios SOLID em GoLang - Prinsip Tanggungjawab Tunggal (SRP)

Dalam dunia pembangunan perisian, prinsip SOLID memberitahu kami cara mengatur fungsi dan data supaya kod kami:

• Bertolak ansur dengan perubahan
• Mudah difahami
• Menjadi asas kepada komponen yang boleh digunakan dalam banyak sistem perisian

Istilah SOLID ialah akronim untuk lima postulat reka bentuk, diterangkan di bawah:

(S) Prinsip Tanggungjawab Tunggal: "Sesuatu modul mesti mempunyai satu dan hanya satu sebab untuk berubah"
(The) Prinsip Terbuka/Tertutup: "Artifak perisian mesti dibuka untuk sambungan tetapi ditutup untuk pengubahsuaian"
(L) Prinsip Penggantian Liskov: "Kelas terbitan mesti boleh digantikan oleh kelas asasnya"
(I) Prinsip Pengasingan Antara Muka: "Sesuatu kelas tidak boleh dipaksa untuk melaksanakan antara muka dan kaedah yang tidak akan digunakan"
(D) Prinsip Penyongsangan Ketergantungan: "Bergantung pada abstraksi dan bukan pelaksanaan"

SOLID dan GoLang

SOLID direka untuk pengaturcaraan berorientasikan objek, dan diketahui bahawa GoLang bukanlah bahasa yang mengamalkan paradigma ini. Walau bagaimanapun, kita boleh menggunakan sumber yang disediakan untuk memenuhi metodologi OOP. Contohnya, Go tidak mempunyai sokongan warisan, tetapi idea itu boleh diberi pampasan dengan sokongan gubahannya. Begitu juga, sejenis polimorfisme boleh dibuat menggunakan antara muka.

Dalam artikel ini, yang pertama dalam siri 5, saya berhasrat untuk memperincikan prinsip pertama dengan contoh yang hampir dengan situasi yang kita hadapi dalam kehidupan seharian.

Prinsip Tanggungjawab Tunggal (SRP)

Kita sudah tahu apa maksud istilah itu, kini tiba masanya untuk mempelajari cara melaksanakannya dalam GoLang.
Dalam bahasa ini, kita boleh mentakrifkan prinsip ini sebagai "Sesuatu fungsi atau jenis mesti mempunyai satu dan hanya satu pekerjaan, dan satu dan hanya satu tanggungjawab", mari lihat kod berikut:

Di atas, kami mempunyai struct yang kami panggil userService. Ia mempunyai dua sifat: db, yang bertanggungjawab untuk berkomunikasi dengan pangkalan data hubungan, dan amqpChannel, yang membolehkan komunikasi dengan perkhidmatan pemesejan RabbitMQ.

UserService melaksanakan kaedah yang dipanggil Cipta. Dalam kaedah ini kami menyimpan maklumat pengguna yang diterima dalam pangkalan data dan kemudian menerbitkan data tersebut ke RabbitMQ.
Dapat dilihat bahawa tanggungjawab kaedah Cipta dalam UserService bukan hanya satu, tetapi dua: menyimpan maklumat dalam pangkalan data dan menerbitkan mesej dalam baris gilir RabbitMQ.

Ini boleh menyebabkan beberapa masalah seperti:

• Sukar untuk dikekalkan: jika salah satu keperluan berubah, seperti cara data pengguna disiri, anda perlu mengubah suai logik kaedah Cipta, walaupun ini tidak ada kena mengena dengan tanggungjawab utama anda, iaitu menyimpan data dalam pangkalan data.
• Kesukaran ujian: Memandangkan kaedah Cipta mempunyai dua tanggungjawab yang berbeza, anda perlu membuat ujian untuk setiap satu, yang boleh menjadi sukar dan menyusahkan.
• Gandingan yang tidak perlu: logik untuk menerbitkan data pengguna ke baris gilir RabbitMQ adalah bebas sepenuhnya daripada logik menyimpan data ini ke pangkalan data. Mencampurkan kedua-dua tanggungjawab ini dalam kaedah yang sama mewujudkan gandingan yang tidak perlu.

Dalam kod berikut, kami mengubah suai struktur untuk menghormati SRP. Semak ia:

Perhatikan bahawa kami telah mengasingkan tanggungjawab kepada tiga bahagian yang berbeza: repositori Repositori Pengguna untuk mengekalkan pengguna ke pangkalan data, penerbit UserPublisher untuk menghantar mesej kepada RabbitMQ, dan perkhidmatan UserServicestrate ini mengendalikan kedua-dua operasi tersebut. .

Dengan cara ini, setiap komponen bertanggungjawab untuk tugas khusus dan bebas, memudahkan penyelenggaraan dan evolusi kod, selain membenarkan setiap bahagian ini diganti atau diperbaiki tanpa menjejaskan bahagian lain. Sebagai contoh, jika perlu menukar pangkalan data yang digunakan, cuma gantikan repositori. Jika perlu menukar bentuk komunikasi, tukar sahaja penerbit.

Perlu diperhatikan bahawa terdapat perbezaan yang ketara antara melaksanakan dua tugas yang berbeza dan mewakilkan pelaksanaannya. Dalam contoh asal userService.Create, dua operasi dilakukan di satu tempat, melanggar prinsip tanggungjawab tunggal. Selepas pemfaktoran semula, kami mewakilkan pelaksanaan kepada struct yang berbeza dan kaedah Cipta hanya bertanggungjawab untuk menyelaraskan aliran ini.

Untuk menggunakan SRP dalam contoh ini, kami juga akhirnya melaksanakan beberapa prinsip SOLID yang lain:

• Prinsip Pengasingan Antara Muka (ISP): setiap antara muka mewakili satu tanggungjawab. Kedua-dua UserRepository dan UserPublisher adalah antara muka yang hanya mempunyai satu kaedah, setiap satu mewakili satu tanggungjawab.
• Prinsip Pembalikan Ketergantungan (DIP): struct UserService bergantung pada abstraksi (antara muka) dan bukan pada pelaksanaan konkrit, iaitu, ia tidak mengetahui pelaksanaan khusus UserRepository dan UserPublisher, hanya antara muka yang mereka laksanakan.
• Prinsip Terbuka/Tertutup (OCP): kod dibuka untuk sambungan kerana repositori atau penerbit baharu boleh ditambah dengan mudah tanpa mengubah suai UserService.

SOLID: 5 Prinsip Pertama Reka Bentuk Berorientasikan Objek
Blog Clean Coder - Prinsip Tanggungjawab Tunggal

Atas ialah kandungan terperinci Principios SOLID em GoLang - Prinsip Tanggungjawab Tunggal (SRP). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!