Trong ph&aacute;t triển phần mềm, Thiết kế hướng đối tượng đ&oacute;ng một vai tr&ograve; quan trọng, gi&uacute;p code của ta linh hoạt, c&oacute; khả năng mở rộng, dễ bảo tr&igrave; v&agrave; c&oacute; thể t&aacute;i sử dụng. Thiết kế Đối tượng (OOD) đem lại rất nhiều lợi &iacute;ch, nhưng mỗi lập tr&igrave;nh vi&ecirc;n cũng n&ecirc;n c&oacute; kiến thức về nguy&ecirc;n tắc SOLID để c&oacute; một thiết kế hướng đối tượng tốt trong lập tr&igrave;nh. Nguy&ecirc;n tắc SOLID được giới thiệu bởi Robert C. codertin, c&ograve;n được gọi l&agrave; Uncle Bob v&agrave; đ&oacute; l&agrave; một ti&ecirc;u chuẩn code h&oacute;a trong lập tr&igrave;nh. SOLID l&agrave; viết tắt của 5 chữ c&aacute;i đầu trong 5 nguy&ecirc;n tắc dưới đ&acirc;y:
<ol style="text-align: justify;">
<li style="font-weight: 400;" aria-level="1">Single responsibility principle (SRP)</li>
<li style="font-weight: 400;" aria-level="1">Open/Closed principle (OCP)</li>
<li style="font-weight: 400;" aria-level="1">Liskov substitution principle (LSP)</li>
<li style="font-weight: 400;" aria-level="1">Interface segregation principle (ISP)</li>
<li style="font-weight: 400;" aria-level="1">Dependency inversion principle (DIP)</li>
</ol>
<img style="width: 600px; display: block; margin-left: auto; margin-right: auto;" src="https://tek4.vn/public_files/17a0318a-726a-4847-bd09-0a954df045ef" alt="SOLID-Principle-in-Programming-Understand-With-Real-Life-Examples" />
SOLID l&agrave; Nguy&ecirc;n tắc thiết kế lập tr&igrave;nh gi&uacute;p giảm sự phụ thuộc lẫn nhau, hay n&oacute;i r&otilde; hơn l&agrave; giảm sự chặt chẽ trong code. Kết hợp chặt chẽ c&oacute; nghĩa l&agrave; một nh&oacute;m c&aacute;c lớp phụ thuộc nhiều v&agrave;o nhau code bạn n&ecirc;n tr&aacute;nh trong code của m&igrave;nh. Tr&aacute;i với khớp nối chặt chẽ l&agrave; khớp nối lỏng lẻo v&agrave; m&atilde; code của bạn được coi l&agrave; tốt khi n&oacute; c&oacute; c&aacute;c lớp được gh&eacute;p nối lỏng lẻo. C&aacute;c lớp được gh&eacute;p nối lỏng lẻo sẽ giảm thiểu những thay đổi trong code của bạn, gi&uacute;p l&agrave;m cho code dễ sử dụng hơn, c&oacute; thể bảo tr&igrave;, linh hoạt v&agrave; ổn định hơn.
<h2>1. Single Responsibility Principle (SRP) - Nguy&ecirc;n tắc đơn tr&aacute;ch nhiệm</h2>
Nguy&ecirc;n tắc n&agrave;y n&oacute;i rằng "Một lớp n&ecirc;n c&oacute; một v&agrave; chỉ một l&yacute; do để thay đổi.", c&oacute; nghĩa l&agrave; mỗi lớp n&ecirc;n c&oacute; một tr&aacute;ch nhiệm duy nhất hoặc một mục đ&iacute;ch duy nhất. V&iacute; dụ, khi ph&aacute;t triển phần mềm, nhiệm vụ được chia cho c&aacute;c th&agrave;nh vi&ecirc;n kh&aacute;c nhau , xử l&yacute; những đầu việc kh&aacute;c nhau, như lập tr&igrave;nh vi&ecirc;n front-end thực hiện thiết kế, tester thực hiện kiểm thử v&agrave; lập tr&igrave;nh vi&ecirc;n backend chịu tr&aacute;ch nhiệm cho phần ph&aacute;t triển back-end. Nh&igrave;n chung mỗi người đảm nhận một c&ocirc;ng việc ri&ecirc;ng.
Thường th&igrave; c&aacute;c lập tr&igrave;nh vi&ecirc;n khi th&ecirc;m t&iacute;nh năng hoặc h&agrave;nh vi mới, họ thực hiện tất cả mọi thứ v&agrave;o lớp hiện c&oacute;. Điều n&agrave;y ho&agrave;n to&agrave;n sai, khiến code d&agrave;i, phức tạp v&agrave; tốn thời gian khi sửa đổi. V&igrave; thế, bạn n&ecirc;n sử dụng c&aacute;c lớp trong ứng dụng v&agrave; chia c&aacute;c lớp qu&aacute; lớn th&agrave;nh c&aacute;c lớp hoặc module nhỏ hơn.
<h2>2. Open/Closed Principle: Nguy&ecirc;n tắc đ&oacute;ng/mở</h2>
Nguy&ecirc;n tắc n&agrave;y n&oacute;i rằng "c&aacute;c thực thể phần mềm (lớp, module, h&agrave;m, v.v.) phải mở cho mở rộng, nhưng đ&oacute;ng để sửa đổi", c&oacute; nghĩa l&agrave; bạn n&ecirc;n c&oacute; thể mở rộng h&agrave;nh vi của một lớp code kh&ocirc;ng cần sửa đổi n&oacute;.
Giả sử lập tr&igrave;nh vi&ecirc;n A cần ph&aacute;t h&agrave;nh một bản cập nhật cho một thư viện hoặc framework v&agrave; lập tr&igrave;nh vi&ecirc;n B muốn thực hiện một số sửa đổi hoặc th&ecirc;m t&iacute;nh năng v&agrave;o đ&oacute;, lập tr&igrave;nh vi&ecirc;n B được ph&eacute;p mở rộng lớp hiện c&oacute; được tạo bởi lập tr&igrave;nh vi&ecirc;n A nhưng kh&ocirc;ng được sửa đổi lớp trực tiếp. Nguy&ecirc;n tắc n&agrave;y t&aacute;ch biệt code hiện c&oacute; v&agrave; code được sửa đổi n&ecirc;n n&oacute; cung cấp độ ổn định, dễ bảo tr&igrave; v&agrave; giảm thiểu sự thay đổi trong code của bạn.
<h2>3. Liskov&rsquo;s Substitution Principle: Nguy&ecirc;n tắc thay thế Liskov&nbsp;</h2>
Nguy&ecirc;n tắc n&agrave;y được giới thiệu bởi Barbara Liskov v&agrave;o năm 1987 v&agrave; theo nguy&ecirc;n tắc n&agrave;y "c&aacute;c lớp dẫn xuất hoặc lớp con phải c&oacute; thể thay thế cho lớp cơ sở hoặc lớp cha của ch&uacute;ng". Nguy&ecirc;n tắc n&agrave;y đảm bảo rằng bất kỳ lớp con n&agrave;o của một lớp cha đều c&oacute; thể sử dụng thay cho lớp cha của n&oacute; code kh&ocirc;ng gặp bất kỳ kh&oacute; khăn n&agrave;o.
V&iacute; dụ bạn l&agrave; con trai của một người n&ocirc;ng d&acirc;n v&agrave; bạn cũng thừa kế việc đồng &aacute;ng của gia đ&igrave;nh m&igrave;nh. Khi cha bạn kh&ocirc;ng thể l&agrave;m việc, th&igrave; bạn sẽ sẵn s&agrave;ng thay thế cha m&igrave;nh nếu cần thiết. Nhưng giả sử con trai của người n&ocirc;ng d&acirc;n ấy muốn trở th&agrave;nh cầu thủ b&oacute;ng đ&aacute; th&igrave; chắc chắn người con trai kh&ocirc;ng thể thay thế cha m&igrave;nh mặc d&ugrave; gia đ&igrave;nh c&oacute; truyền thống l&agrave;m n&ocirc;ng.
Một trong những v&iacute; dụ l&acirc;u đời của nguy&ecirc;n tắc n&agrave;y l&agrave; h&igrave;nh chữ nhật c&oacute; bốn cạnh. Chiều cao v&agrave; chiều rộng của một h&igrave;nh chữ nhật c&oacute; thể l&agrave; bất kỳ gi&aacute; trị n&agrave;o. Một h&igrave;nh vu&ocirc;ng l&agrave; một h&igrave;nh chữ nhật với chiều rộng v&agrave; chiều cao bằng nhau. V&igrave; vậy, ch&uacute;ng ta c&oacute; thể mở rộng c&aacute;c thuộc t&iacute;nh của lớp h&igrave;nh chữ nhật th&agrave;nh lớp h&igrave;nh vu&ocirc;ng. Để l&agrave;m được điều đ&oacute;, bạn cần thay thế lớp con (h&igrave;nh vu&ocirc;ng) bằng lớp cha (h&igrave;nh chữ nhật) để ph&ugrave; hợp với định nghĩa của một h&igrave;nh vu&ocirc;ng c&oacute; bốn cạnh bằng nhau, nhưng một lớp dẫn xuất kh&ocirc;ng ảnh hưởng đến h&agrave;nh vi của lớp cha. V&igrave; nếu bạn l&agrave;m như vậy, điều đ&oacute; sẽ vi phạm Nguy&ecirc;n tắc thay thế Liskov.&nbsp;
<h2>4. Interface Segregation Principle: Nguy&ecirc;n tắc ph&acirc;n t&aacute;ch giao diện</h2>
Nguy&ecirc;n tắc n&agrave;y l&agrave; nguy&ecirc;n tắc đầu ti&ecirc;n &aacute;p dụng cho c&aacute;c giao diện chứ kh&ocirc;ng phải c&aacute;c lớp trong SOLID v&agrave; n&oacute; tương tự như nguy&ecirc;n tắc đơn tr&aacute;ch nhiệm. Nguy&ecirc;n tắc n&agrave;y n&oacute;i rằng "kh&ocirc;ng &eacute;p buộc bất kỳ kh&aacute;ch h&agrave;ng n&agrave;o phải c&agrave;i đặt một giao diện code kh&ocirc;ng li&ecirc;n quan đến họ". Ở đ&acirc;y, mục ti&ecirc;u ch&iacute;nh của bạn l&agrave; tập trung v&agrave;o việc tr&aacute;nh c&aacute;c giao diện qu&aacute; to v&agrave; ưu ti&ecirc;n c&aacute;c giao diện nhỏ ph&ugrave; hợp với kh&aacute;ch h&agrave;ng cụ thể. Bạn n&ecirc;n ưu ti&ecirc;n nhiều giao diện kh&aacute;ch h&agrave;ng hơn l&agrave; một giao diện chung v&agrave; mỗi giao diện n&ecirc;n c&oacute; một nhiệm vụ cụ thể.
Giả sử bạn l&agrave; một người ăn chay, v&agrave; c&oacute; dịp đi ăn tại nh&agrave; h&agrave;ng. Người phục vụ đưa cho bạn menu bao gồm c&aacute;c m&oacute;n ăn chay, mặn, đồ uống v&agrave; mứt ngọt. Trong trường hợp n&agrave;y, nếu bạn l&agrave; kh&aacute;ch h&agrave;ng, bạn n&ecirc;n y&ecirc;u cầu một thực đơn chỉ c&oacute; c&aacute;c m&oacute;n chay, chứ kh&ocirc;ng phải những thứ m&agrave; bạn kh&ocirc;ng muốn ăn. Ở đ&acirc;y, menu n&ecirc;n kh&aacute;c nhau đối với c&aacute;c loại kh&aacute;ch h&agrave;ng kh&aacute;c nhau. Thẻ menu chung cho mọi người n&ecirc;n chia th&agrave;nh nhiều thẻ. Nguy&ecirc;n tắc n&agrave;y gi&uacute;p giảm thiểu c&aacute;c t&aacute;c động phụ v&agrave; tần suất sửa đổi.
<h2>5. Dependency Inversion Principle: Nguy&ecirc;n tắc đảo ngược sự phụ thuộc&nbsp;</h2>
Trước khi ch&uacute;ng ta thảo luận về chủ đề n&agrave;y, h&atilde;y nhớ rằng Nguy&ecirc;n tắc đảo ngược sự phụ thuộc v&agrave; Dependency Injection l&agrave; hai kh&aacute;i niệm kh&aacute;c nhau. Hầu hết mọi người bị nhầm lẫn v&agrave; cho rằng cả hai giống nhau. Nguy&ecirc;n tắc n&agrave;y c&oacute; hai điểm ch&iacute;nh như sau:
<ul style="text-align: justify;">
<li style="font-weight: 400;" aria-level="1">C&aacute;c module / lớp cấp cao kh&ocirc;ng n&ecirc;n phụ thuộc v&agrave;o c&aacute;c module / lớp cấp thấp. Cả hai n&ecirc;n phụ thuộc v&agrave;o c&aacute;c abstraction.</li>
<li style="font-weight: 400;" aria-level="1">C&aacute;c abstraction kh&ocirc;ng n&ecirc;n phụ thuộc v&agrave;o chi tiết. Chi tiết n&ecirc;n phụ thuộc v&agrave;o c&aacute;c abstraction.</li>
</ul>
Những d&ograve;ng tr&ecirc;n đơn giản chỉ n&oacute;i rằng nếu một module hoặc lớp cấp cao phụ thuộc nhiều v&agrave;o c&aacute;c module hoặc lớp cấp thấp th&igrave; code của bạn sẽ c&oacute; sự li&ecirc;n kết chặt chẽ v&agrave; nếu bạn cố gắng thay đổi một lớp th&igrave; n&oacute; c&oacute; thể l&agrave;m hỏng một lớp kh&aacute;c, đ&acirc;y l&agrave; rủi ro lớn ở cấp độ sản xuất. V&igrave; vậy, h&atilde;y cố gắng l&agrave;m cho c&aacute;c lớp được kết nối chặt chẽ &iacute;t nhất c&oacute; thể v&agrave; bạn c&oacute; thể đạt được điều n&agrave;y th&ocirc;ng qua abstraction. Mục đ&iacute;ch ch&iacute;nh của nguy&ecirc;n tắc n&agrave;y l&agrave; giải ph&oacute;ng c&aacute;c phụ thuộc, v&igrave; vậy nếu lớp A thay đổi th&igrave; lớp B kh&ocirc;ng cần quan t&acirc;m hoặc biết về những thay đổi đ&oacute;.
Ch&uacute;ng ta c&oacute; thể d&ugrave;ng pin ở điều khiển TV l&agrave;m v&iacute; dụ. Điều khiển cần một vi&ecirc;n pin nhưng thương hiệu của vi&ecirc;n pin th&igrave; kh&ocirc;ng quan trọng. Bạn c&oacute; thể sử dụng bất kỳ thương hiệu XYZ n&agrave;o bạn muốn v&agrave; điều khiển vẫn hoạt động b&igrave;nh thường. Như vậy, điều khiển TV được kết nối lỏng lẻo với t&ecirc;n thương hiệu. Nguy&ecirc;n tắc Đảo ngược sự phụ thuộc gi&uacute;p code của bạn dễ t&aacute;i sử dụng hơn.
N&ecirc;́u bạn th&acirc;́y bài vi&ecirc;́t hữu ích thì hãy ti&ecirc;́p tục theo dõi và ủng h&ocirc;̣ các bài vi&ecirc;́t ti&ecirc;́p theo của Tek4.vn nhé!

Bich Huong

Nguyên tắc SOLID trong lập trình: Ví dụ thực tế

Cùng tác giả

Bich Huong

Có liên quan