Cách SOLID vẫn vững chắc - Nguyên tắc phần mềm so với các mẫu

Mar 22 2022
Thẳng thắn và đơn giản Lần trước, chúng ta đã đề cập đến sự khác biệt giữa Đảo ngược phụ thuộc và Tiêm phụ thuộc. Cả hai đều là những khái niệm quan trọng giúp chúng tôi xây dựng phần mềm tốt hơn.

Thẳng thắn và đơn giản

Ảnh của Artem Kniaz trên Unsplash

Lần trước, chúng tôi đã đề cập đến sự khác biệt giữa Đảo ngược phụ thuộc & Tiêm phụ thuộc . Cả hai đều là những khái niệm quan trọng giúp chúng tôi xây dựng phần mềm tốt hơn. Tuy nhiên, một trong những điểm khác biệt chính là Dependency Injection là một mẫu và Dependency Inversion là một nguyên tắc.

Hôm nay chúng ta sẽ thảo luận về lý do tại sao đó lại là một sự khác biệt quan trọng.

Nguyên tắc là gì?

Nguyên tắc là chân lý cơ bản. Chúng đóng vai trò là nền tảng mà dựa vào đó người ta có thể xây dựng các hệ thống và lý thuyết phức tạp hơn. Khi nói đến việc tạo ra những thứ mới, các nguyên tắc là rất quan trọng. Chúng cho phép chúng tôi đạt được kết quả theo cấp số nhân , bằng cách kết nối các dấu chấm theo những cách mới và chưa từng có trước đây. Các nguyên tắc đóng vai trò như một liều thuốc giải độc cho sự thay đổi không ngừng của thế giới, một sự thay đổi dường như đang tăng tốc .
Ví dụ về các nguyên tắc có thể được tìm thấy trong mọi lĩnh vực của cuộc sống:

  • Trong Kỹ thuật phần mềm, chúng tôi có các nguyên tắc thiết kế SOLID .
  • Trong Tâm lý học, chúng ta có nguyên tắc niềm vui .
  • Trong Vật lý, chúng ta có các nguyên tắc của chuyển động .
  • Ảnh của Dan Clear trên Unsplash

Các mẫu đơn giản là một thứ gì đó tự lặp lại theo cách có thể đoán trước được.
Bộ não của chúng ta rất giỏi trong việc xác định các mẫu. Không chỉ vậy, họ rất giỏi trong việc dự đoán những gì mà những mô hình đó ngụ ý, bằng cách sử dụng tư duy quy nạp.
Ví dụ về các Mẫu cũng có thể được tìm thấy trong mọi lĩnh vực của cuộc sống:

  • Trong Kỹ thuật phần mềm, chúng tôi có các mẫu thiết kế .
  • Trong ngành công nghiệp thời trang, chúng tôi có các mẫu làm mẫu .
  • Trong tự nhiên, chúng ta có các mô hình trực quan về đối xứng, fractal, và hơn thế nữa.
  • Ảnh của JJ Ying trên Unsplash

Tất cả chúng ta đều đang tìm kiếm thứ gì đó ổn định để dựa vào, dựa trên một số sự thật cơ bản vượt qua bối cảnh và công nghệ đang thay đổi. Chà, không cần tìm đâu xa, Nguyên tắc chính là thứ chúng ta cần.

Nhu cầu của con người về thực phẩm là một nguyên tắc. (Ngoại trừ những người biết thở , chúng tuyên bố sống sót nhờ không khí và ánh nắng mặt trời). Bạn có thể dựa vào đó như một tiên đề, nó sẽ không thay đổi chừng nào con người vẫn là con người.

Ngược lại, nhu cầu ăn Pizza của con người là một hình mẫu. Nếu bạn đi giữa những người trẻ tuổi, đặc biệt là các kỹ sư phần mềm trẻ, nó gần giống như một nguyên tắc - Pizza thật tuyệt vời và nó phải là nhu cầu cơ bản của con người. Tuy nhiên, giống như các mẫu khác, tình yêu dường như phổ biến của chúng ta đối với Pizza phụ thuộc vào ngữ cảnh. Nếu bạn đang ăn kiêng, một chiếc Pizza sẽ nhanh chóng biến thành Đồ chống đối - điều cần tránh bằng mọi giá.

Các nguyên tắc trong kỹ thuật phần mềm

Trong thế giới Kỹ thuật phần mềm, chúng tôi cũng có những nguyên tắc làm kim chỉ nam cho chúng tôi khi thiết kế phần mềm.

Lấy Dependency Inversion làm ví dụ. Đó là một phần trong 5 nguyên tắc cốt lõi của SOLID . Tóm lại - nó có nghĩa là chúng ta nên phụ thuộc vào những điều trừu tượng, chứ không phải những triển khai cụ thể. Nguyên tắc này giúp chúng tôi thiết kế phần mềm mạnh mẽ và có thể bảo trì. Không có bối cảnh nào buộc chúng ta phải ủng hộ các triển khai cụ thể hơn là các phần trừu tượng, vì chi phí sử dụng các phần trừu tượng là không đáng kể, trong khi chi phí của một sự thay đổi đối với một triển khai cụ thể là có thể không bị giới hạn.

Các mẫu trong Kỹ thuật phần mềm

Thế giới Kỹ thuật phần mềm cũng có đầy rẫy những khuôn mẫu, một số trong số chúng bị coi là “xấu” và chúng tôi có xu hướng gọi chúng là “Anti-Patterns”, đáng nhớ nhất trong số đó là “Spaghetti Code” đáng sợ. Trong khi một số được coi là “tốt” và chúng tôi chỉ đơn giản gọi chúng là “Mẫu thiết kế”.

Anti-pattern được coi là hành vi xấu, con đường dẫn đến vô số rắc rối và lỗi, một dấu hiệu của các kỹ sư thiếu kinh nghiệm. Chúng là thứ cần phải tránh bằng mọi giá. Chúng vẫn được coi là các mẫu vì chúng có xu hướng xảy ra khá dễ đoán, đặc biệt là với các kỹ sư thiếu kinh nghiệm. Trong ví dụ về “Spaghetti Code”, đó chỉ đơn giản là một biểu hiện của suy nghĩ vô tổ chức, có xu hướng xảy ra một cách tự nhiên khi cố gắng giải quyết một vấn đề mà không có kế hoạch hoặc kinh nghiệm trước.

Các mẫu thiết kế được coi là thông lệ tốt - sử dụng kinh nghiệm tập thể của chúng tôi với tư cách là kỹ sư phần mềm để tìm ra giải pháp tốt cho các vấn đề chung. Vấn đề là, đôi khi ngay cả những mẫu “tốt” cũng có thể bị lạm dụng, có khả năng biến chúng thành những Mẫu chống đối.

Các mẫu thiết kế - Tốt, xấu và có thể

Ảnh của Caroline Hall trên Unsplash

Có rất nhiều ví dụ về các mẫu thiết kế, nhưng theo nguyên tắc chung, một mẫu thiết kế tốt bắt nguồn từ các nguyên tắc thiết kế.
Ví dụ: Dependency Injection là một mẫu thiết kế tuyệt vời cho phép chúng ta tách việc tạo ra khỏi việc sử dụng. Nó làm giảm sự ghép nối, cải thiện kiểm tra và bắt nguồn từ các nguyên tắc thiết kế - nó là sự triển khai của Nguyên tắc đảo ngược phụ thuộc.

Tuy nhiên, một số mẫu không được chấp nhận rộng rãi, chủ yếu là do chúng không bắt rễ sâu vào các nguyên tắc thiết kế.
Ví dụ, hãy xem mẫu Singleton. Hầu hết mọi người coi nó là một mẫu thiết kế hữu ích. Nó được sử dụng trong các trường hợp chỉ cần một cá thể duy nhất của một lớp và việc có nhiều cá thể có thể gây bất lợi. Mẫu này rất hữu ích khi chúng ta muốn tạo một phiên bản duy nhất cho bộ nhớ cache, tệp cấu hình hoặc trình ghi nhật ký.

Tuy nhiên, một số người coi nó là một Anti-Pattern. Một khiếu nại phổ biến là mẫu vi phạm Nguyên tắc trách nhiệm duy nhất (Chữ S trong SOLID) vì nó kiểm soát vòng đời của nó và thực thi hành vi cá thể đơn lẻ trên chính nó. Theo ý kiến ​​của tôi, điều đó không hoàn toàn chính xác, vì điều khiển phiên bản là trực giao với chức năng và SRP đề cập đến chức năng. Một tuyên bố hợp lệ hơn là Singletons vi phạm Nguyên tắc đảo ngược phụ thuộc, vì bạn phụ thuộc vào việc triển khai cụ thể - truy cập Singleton thông qua các phương thức tĩnh cụ thể của nó, thay vì dựa vào các nội dung trừu tượng. Điều này dẫn đến khớp nối chặt chẽ khiến cho mã của chúng ta ít khả năng bảo trì hơn và dễ bị lỗi hơn nếu các thay đổi xảy ra.
Điều đó không có nghĩa là mẫu Singleton vốn đã xấu, nhưng nếu có vẻ như một mẫu đang vi phạm các nguyên tắc, bạn nên thận trọng trước khi thực hiện nó.

Những gì chúng ta đã học được hôm nay

Trong Kỹ thuật phần mềm, cũng như trong cuộc sống, chúng ta có các khuôn mẫu và chúng ta có các nguyên tắc. Phát hiện các mẫu và sử dụng chúng để giải quyết các vấn đề chung có thể vô cùng hữu ích. Tuy nhiên, các mẫu không ăn sâu vào các nguyên tắc có thể trở thành Phản mẫu - gây ra nhiều vấn đề hơn là chúng giải quyết được.

Lần tới khi bạn thấy mình đang tìm hiểu về một mẫu thiết kế mới hoặc thậm chí muốn triển khai một mẫu hiện có, hãy tự hỏi bản thân - Mẫu này có bắt nguồn từ các nguyên tắc thiết kế vững chắc (dự định chơi chữ) không? Hoặc nó có thể có khả năng gây ra các vấn đề không lường trước được?

Tôi hy vọng bạn thấy bài viết này hữu ích và cho đến lần sau, hãy giữ nó thẳng thắn và đơn giản!

© Copyright 2021 - 2023 | vngogo.com | All Rights Reserved