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:

Prinsip Tanggungjawab Tunggal (S): "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 setiap hari.

Prinsip Tanggungjawab Tunggal (SRP)

Kita sudah tahu 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 tugas, 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 membawa kepada 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 tiada kaitan dengan tanggungjawab utama anda, iaitu untuk simpan data dalam pangkalan data.
Kesukaran ujian: kerana kaedah Cipta mempunyai dua tanggungjawab yang berbeza, anda perlu membuat ujian untuk setiap ujian, 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. Lihatlah:

Perhatikan bahawa kami telah memisahkan tanggungjawab kepada tiga bahagian yang berbeza: repositori UserRepository untuk meneruskan pengguna ke pangkalan data, penerbit UserPublisher untuk menghantar mesej kepada RabbitMQ dan perkhidmatan UserService yang mengatur kedua-dua operasi ini.

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, hanya gantikan repositori. Jika perlu menukar bentuk komunikasi, cuma tukar penerbit.

Perlu diambil perhatian bahawa terdapat perbezaan yang ketara antara melaksanakan dua tugasan yang berbeza dan mewakilkan pelaksanaannya. Dalam contoh userService.Create asal, 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 ialah antara muka yang hanya mempunyai satu kaedah, setiap satu mewakili satu tanggungjawab.
• Prinsip Penyongsangan 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.

Dalam artikel seterusnya dalam siri ini saya akan memberikan penjelasan yang lebih terperinci tentang setiap satu daripada mereka, dengan contoh khusus.

Jumpa lagi, kawan-kawan!

Rujukan:
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!