Solid principles là gì

     

Video học tập lập trình mỗi ngày

SOLID là gì? nguyên lý SOLID được hiểu như vậy nào? Tôi đang đọc trải qua không ít bài báo, thiệt sự nhưng mà nói, những bài báo vô cùng học thuật và cực kỳ máy móc. Dành riêng 1 giờ đi kiếm hiểu về SOLID mà chạm mặt những bài xích báo câu lượt thích câu view chán thật. Thiệt sự nhưng mà nói, tôi từ vứt java cách đó 5 năm để chuyển sang làm cho BE. Nhưng mà trước khi đến với BE thì tôi cũng đã có lần nghe nói về nguyên tắc SOLID của Uncle Bob, nghe nói không giống với định nghĩa hiểu. Bởi vì vậy sau bao năm, thì hôm qua tôi chạm mặt một nội dung bài viết quảng cáo trên FB, nói về SOLID là gì? vị sao nó lại quan trọng trong xây đắp phần mềm?

Chính do thế, tôi quyết định đi kiếm hiểu lại một lượt nữa, cùng cũng là xác định rằng mẫu gì không hiểu biết thì bọn họ sẽ mày mò lại môt lần nữa. Đương nhiên, lúc tôi gọi thì các bạn cũng hiểu, đó cũng là phương châm của blog này. Trong nội dung bài viết này các bạn sẽ nghe được một vài cụm từ như OOP, OOD, SOLID cùng quang trọng là các ví dụ thực tiễn trong cuộc sống đời thường của chúng ta.

Bạn đang xem: Solid principles là gì

SOLID là gì?

OOD viết tắt trường đoản cú Object-Oriented Design, xét về nghành phát triển ứng dụng thì OOD đóng vài trò đặc biệt quan trọng giúp các bạn viết code một giải pháp linh hoạt, không ngừng mở rộng dễ dàng, có thể giúp ngắn thời gian duy trì và hơn nữa là tái sử dụng, huyết kiệm được không ít thời gian hơn. Nói bởi vậy nó liên quan gì mang lại khái niệm SOLID làm việc đây, đúng không liên quan những các bạn cũng nên gồm kiến ​​thức về qui định SOLID để thi công hướng đối tượng người sử dụng tốt trong lập trình. Lý lẽ SOLID được trình làng bởi đại ca Robert C. Martin , còn gọi là Uncle Bobvà nó là 1 trong những tiêu chuẩn mã hóa trong lập trình. Vẻ ngoài SOLID này là từ viết tắt của năm phép tắc được đưa ra dưới đây

Single Responsibility Principle (SRP)Open/Closed PrincipleLiskov’s Substitution Principle (LSP)Interface Segregation Principle (ISP)Dependency Inversion Principle (DIP)

Đừng sợ, chớ đóng bài ở đây, bạn tương tự như tôi khi quan sát vào 5 hình thức này thì không phát âm nữa, nhưng lại hãy tạm dừng bởi vì nội dung bài viết này không có tý code nào hết, mà phân tích và lý giải bằng những câu chuyện đời thường nhưng mà thôi. Tin tôi đí, bạn có một phút thôi. OK chứ? trước lúc đi vào lý giải 5 hiệ tượng trên tề thì, cũng nên văn vở một chút.

SOLID là Nguyên tắc xây đắp lập trinh giúp sút sự dựa vào lẫn nhau, tốt nói rõ hơn là bớt sự chặt chẽ trong code. Kết hợp ngặt nghèo có nghĩa là 1 trong nhóm các lớp phụ thuộc nhiều vào với nhau mà chúng ta nên tránh vào mã của mình. Đối lập cùng với khớp nối ngặt nghèo là khớp nối lỏng lẻo cùng mã của người tiêu dùng được xem như là mã xuất sắc khi nó có những lớp được ghép nối lỏng lẻo. Những lớp được ghép nối từ từ sẽ bớt thiểu những chuyển đổi trong mã của bạn, giúp làm cho mã dễ thực hiện hơn, có thể bảo trì, linh hoạt và ổn định hơn.

Bây giờ mang lại lượt tôi, lý giải theo đẳng cấp dân thường...

Single Responsibility Principle (SRP) - Nguyên tắc trách nhiệm Duy nhất

Nguyên tắc này bảo rằng một lớp chỉ nên có một tại sao để biến đổi có nghĩa là từng lớp phải bao gồm một trách nhiệm duy tuyệt nhất hoặc một các bước hoặc một mục đích duy nhất. Đó là định nghĩa, còn chúng ta và tôi phát âm dưới đây là được.

Ví dụ trong cuộc sống đời thường đời thường, mặt đường một chiều là 1 trong những ví dụ điển hình, đường một chiều chỉ có tác dụng một bài toán là đi về một hướng, cấp tốc gọn bình an hơn mặt đường hai chiều. Đường nhị chiều luôn nguy hiểm, nguy cơ rủi ro hơn nhiều. Single Responsibility Principle (SRP

Giống như vào team thao tác vậy, demo một cỗ phận, code một cỗ phận, thiết kế một cỗ phận... Chứ 1 mình làm như fullstack thì khổ, cái gì cũng đụng, mà chăm thì được mấy chỗ, sót lại là làm cho cho dứt là được. Ok vậy thôi, nói tầm thường là hiểu tư tưởng SRP do vậy là ok rồi.

Open/Closed Principle - nguyên tắc Mở / Đóng

Nguyên tắc này bảo rằng `các thực thể phần mềm (class, module, function, v.v.) buộc phải mở để mở rộng, dẫu vậy đóng để sửa đổi bao gồm nghĩa là chúng ta có thể mở rộng hành động của class nhưng không đề xuất sửa thay đổi nó. Hiểu thực tiễn xem ..

Ví dụ trong cuộc sống thường ngày đời hay Code A làm một module như vậy này:

class IceCreamMachine constructor() this.flavors = <"chocolate", "vanilla">; create() if (this.flavors.includes(flavor)) // warning, ES7 Array.prototype.includes console.log("Great success. You now can eat your ice cream"); else console.log("A bad choice, not ice cream today"); export mặc định IceCreamMachineA đóng gói lại, giờ đây chỉ có hai hương vị kem nhưng thôi <"chocolate", "vanilla">. Giờ B hy vọng bán kem và muốn thêm một mùi vị nữa vào và đặc biệt là không muốn sửa code của A thì làm cho sao, làm cầm cố này nè:

class IceCreamMachine constructor() this.flavors = <"chocolate", "vanilla">; create() if (this.flavors.includes(flavor)) console.log("Great success. You now can eat your ice cream"); else console.log("A bad choice, not ice cream today"); flavorAdd(flavor) this.flavors = <...this.flavors, flavor>; Để tuân thủ theo đúng OCP, chúng ta cũng có thể dễ dàng biến đổi điều đó với flavorAdd().

Xem thêm: Lời Bài Hát Bước Qua Thế Giới, Bước Qua Thế Giới (Phan Mạnh Quỳnh)

Ngon chưa, hiểu dễ dàng hơn chưa??? Tiếp hén.

Liskov’s Substitution Principle (LSP) - Nguyên tắc sửa chữa Liskov

Nguyên tắc thay thế Liskov đúng là khó hiểu nhất trong số những khái niệm lập trình. Vẻ ngoài được đưa ra vày Barbara Liskov vào khoảng thời gian 1987 với theo cách thức này:

Các lớp nhỏ hoặc lớp con yêu cầu được sửa chữa thay thế cho các lớp cơ sở hoặc lớp phụ vương của chúng. Hiệ tượng này đảm bảo rằng ngẫu nhiên lớp nào là con của lớp thân phụ đều hoàn toàn có thể sử dụng được nỗ lực cho lớp thân phụ của nó nhưng mà không có ngẫu nhiên khó khăn nào.

Đọc xong, không hiểu nhiều luôn, tuy vậy hãy xem lấy một ví dụ đời thường. Ví dụ chúng ta là người nam nhi của một fan nông dân và chúng ta cũng vượt kế việc làm đồng án của gia đình mình, khi thân phụ của chúng ta không thể thao tác làm việc đồng án, thì các bạn sẽ sẵn sàng gắng thế phụ thân mình nều đề nghị thiết. Tuy nhiên giả sử nếu con trai của fan nông dân ấy mong muốn trở thành cầu thủ đá bóng thì chắc chắn người đàn ông không thể rứa thế phụ vương mình tuy nhiên cả hai phần nhiều thuộc gia đình Nông Dân. Nguyên tắc sửa chữa thay thế Liskov

Một giữa những ví dụ truyền thống của cơ chế này là một trong những hình chữ nhật có bốn cạnh và hình vuông. Thiệt ra hình vuông cũng là hình chữ nhật, chỉ là các cạnh nó bằng nhau, chỉ cần làm tác dụng cho hình chữ nhật thì sẽ làm cho được hình vuông. Xem đoạn phim Nguyên tắc thay thế sửa chữa Liskov về nhằm hiểu hơn.

Interface Segregation Principle (ISP) - hình thức phân bóc giao diện

Nguyên tắc này là nguyên tắc đầu tiên áp dụng cho các Giao diện thay vì chưng các phần trong SOLID với nó giống như như nguyên tắc thứ nhất Single Responsibility Principle (SRP) chúng ta cũng có thể đọc lại nếu chưa rõ. Vày trong javascript không có interfaces nên các bạn cũng không cần thân thiết cho lắm, nhưng không có nghĩa là không nên hiểu. Nguyên tắc thay thế sửa chữa Liskov

Giả sử nếu bạn bước vào một nhà hàng và chúng ta là người dùng đồ chay trường. Khi chúng ta ngồi vào bàn, thì người phục vụ sẽ đưa cho bạn một menu trong đó bao hàm các món không chay, chay... Tùm lum và hỗn loạn. Các bạn sẽ mất thời gian chọn lựa điều đó sẽ khiến bạn ko hài lòng. Trong trường hòa hợp này, cùng với tư bí quyết là khách hàng hàng, chúng ta nên có một thực đơn riêng chỉ bao hàm các món chay, không phải toàn bộ những gì các bạn không ăn trong thực phẩm của mình. Ở trên đây thực 1-1 nên khác nhau cho những loại người tiêu dùng khác nhau. Menu thông thường hoặc tầm thường cho những người hoàn toàn có thể được tạo thành nhiều menu thay bởi vì chỉ một Menu. áp dụng nguyên tắc này giúp giảm các tính năng phụ và tần suất đổi khác cần thiết.

Dependency Inversion Principle (DIP) - Nguyên tắc đảo ngược phụ thuộc

Trước khi bọn chúng ta đàm đạo về chủ thể này, hãy nhớ rằng Dependency Inversion cùng Dependency Injection cả hai phần đa là phần đông khái niệm không giống nhau. Phần đông mọi fan đều lầm lẫn về nó và coi cả hai số đông giống nhau. Bây chừ hai điểm chính tại đây cần ghi ghi nhớ về phép tắc này.

High-level modules/classes không nên nhờ vào vào low-level modules/classes. Cả hai hồ hết phải nhờ vào vào abstractions.

Xem thêm: Top 16 Đến Sau Này Chúng Ta Già Mới Nhất 2022, Hạnh Phúc Cuối Cùng

Tóm tắt ko nên phụ thuộc vào đưa ra tiết. Thông tin cụ thể nên dựa vào vào sự trừu tượng. Cực nhọc hiểu cho các ai trước đó chưa từng viết về ngôn từ JAVA. Dẫu vậy không sao chúng ta hay coi xét vấn đề này sang một ví dụ thực tiễn dưới đây. Dependency Inversion Principle (DIP)

Bạn có thể xem xét ví dụ thực tiễn về pin tinh chỉnh TV. Điều khiển trường đoản cú xa của bạn cần pin mà lại không phụ thuộc vào uy tín pin. Chúng ta có thể sử dụng ngẫu nhiên nhãn hiệu XYZ nào bạn muốn và nó sẽ chuyển động mà không đề xuất quan tâm bạn đang xài hàng nào. Bởi vậy, chúng tôi có thể nói rằng điều khiển từ xa TV được kết hợp lỏng lẻo với thương hiệu thương hiệu. Dependency Inversion tạo nên mã của bạn có thể tái áp dụng nhiều hơn. Chốt hạ tự đây, ok.

Bài viết có xem thêm từ: SOLID Principle in Programming: Understand With Real Life Examples 5 principles that will make a more SOLID Javascript Engineer