“Tạo ra phần lớn dòng code giúp những developer dễ dàng đọc, dễ nắm bắt và dễ soát sổ khi hợp tác ký kết cùng nhau.”

Các SOLID principles rất có thể được thực hiện để phát triển ứng dụng với mục tiêu dễ bảo trì và mở rộng khi dự án công trình phát triển. Việc vận dụng các cách thức này cũng sẽ góp phần tái cấu tạo codebase lịch sự trạng thái dễ bảo trì hơn hoặc thậm chí vận dụng các phương pháp Agile!

Nói một cách đối chọi giản, các nguyên tắc xây dựng của Martin và Feathers khích lệ lập trình viên tạo ra những phần mềm dễ bảo trì, dễ dàng nắm bắt và linh động hơn. Toàn bộ những ai đã từng lập trình cũng mọi biết rằng bảo trì code (như là thêm chức năng, sửa lỗi,…) new là phần tốn nhiều thời hạn nhất trong quy trình phát triển.

Nhờ tất cả SOLID, khi các ứng dụng cách tân và phát triển quy mô, bạn cũng có thể giảm độ phức tạp và hạn chế những vấn đề rủi ro trong tương lai.

Việc làm Developer TP. HCM

Việc làm Developer Hà Nội

Ngoài ra, bạn cũng có thể ghi lưu giữ thêm một vài design Pattern thông dụng trong lập trình sẵn hướng đối tượng người tiêu dùng OOP vị ITviec tổng hợp.

SOLID là viết tắt từ năm chữ loại đầu của năm qui định sau:

Một class nên làm có một nhiệm vụ. Rộng nữa, mỗi class nên làm có một vì sao để thế đổi.

Vì sao nguyên tắc Đơn nhiệm lại đặc trưng như vậy?

Trước hết, do nhiều team khác nhau có thể làm câu hỏi trong cùng một dự án nên nếu như một class có tương đối nhiều hơn một trách nhiệm, thì những team kia phải thao tác làm việc trên và một class và chỉnh sửa cùng một class bởi những vì sao khác nhau, điều này hoàn toàn có thể dẫn đến những module không tương thích.

Lý vì thứ hai, hiệ tượng Đơn nhiệm giúp cho việc điều hành và kiểm soát phiên bạn dạng trở nên thuận tiện hơn. Ví dụ: trả sử ta có một persistence class dùng làm xử lý các hoạt động của cơ sở dữ liệu và họ nhận thấy tất cả một biến hóa trong tệp đó ở Git
Hub commit. Bằng cách làm theo nguyên tắc Đơn nhiệm, bọn họ sẽ thuận tiện biết rằng biến đổi đó liên quan đến lưu trữ hay liên quan đến cửa hàng dữ liệu.

Ví dụ: Ta hãy nhìn vào một trong những class đại diện thay mặt cho một cuốn sách đối chọi giản:

public class Book private String name; private String author; private String text; //constructor, getters với settersTrong đoạn code này, họ lưu trữ tên, người sáng tác và văn bạn dạng được link với một phiên bạn dạng của Book.

Bây giờ bọn họ hãy thêm một vài cách tiến hành để truy tìm vấn văn bản:

public class Book private String name; private String author; private String text; //constructor, getters cùng setters //các phương thức liên quan trực tiếp đến thuộc tính Book public String replace
Word
In
Text(String word, String replacement
Word) return text.replace
All(word, replacement
Word); public boolean is
Word
In
Text(String word) return text.contains(word); Để tương khắc phục chứng trạng “thiếu trơ trẽn tự” trên, họ nên tiến hành một class riêng rẽ chỉ xử lý việc in văn bản:

public class Book
Printer //phương thức mang đến văn bạn dạng đầu ra void print
Text
To
Console(String text) //code dùng để định dạng và in văn phiên bản void print
Text
To
Another
Medium(String text) //code dùng để viết cho những phương tiện khác Chúng ta không những phát triển một class giúp giảm bớt nhiệm vụ in Book mà họ còn hoàn toàn có thể tận dụng class Book
Printer để gửi văn phiên bản tới những phương một thể khác. Dù đó là email, nhật ký kết hoạt động, hay ngẫu nhiên phương nhân tiện gì, bọn họ đang có một class riêng dành riêng cho nhiệm vụ này.

Các đối tượng người sử dụng hoặc thực thể cần “mở cửa” với mở rộng nhưng “đóng cửa” với sửa đổi.

Trong đó:

Vì vậy, nội dung chế độ Mở/đóng bao gồm nghĩa là: chúng ta có thể thêm chức năng mới nhưng mà không đề xuất đụng vào code hiện gồm của class.

Nguyên nhân là do bất cứ lúc nào ta sửa thay đổi code hiện nay có, luôn luôn sẽ có nguy hại tạo ra những lỗi tiềm ẩn. Do vậy, nếu bao gồm thể, bọn họ nên tránh va vào code sẽ được khám nghiệm và đang hoạt động ổn.

Vậy thì làm rứa nào để chúng ta thêm tính năng mới mà không phải đụng vào class đó? họ chỉ cần kế thừa hoặc thiết lập class đó. Hãy cho với ví dụ như sau:

Hãy test tưởng tượng bọn họ đang xúc tiến một class Guitar. Đây là một chiếc guitar hoàn hảo và có cả nút chỉnh âm lượng:

public class Guitar private String make; private String model; private int volume; //constructors, getters và settersSau một vài ba tháng, chúng ta thấy rằng Guitar chú ý hơi chán và ta ao ước thêm kiểu thiết kế hình ngọn lửa để gia công cho dòng guitar này trông “chất” hơn.

Lúc này đây, sẽ sở hữu một vài bạn muốn mở class Guitar ra và thêm ngay hoa văn ngọn lửa vào đó tuy nhiên ai hiểu rằng những lỗi nào có thể xuất hiện nay trong ứng dụng nếu họ làm như vậy.

Thay vào đó, hãy tuân theo phép tắc Mở/đóng và chỉ cần mở rộng lớn class Guitar:

public class Super
Cool
Guitar
With
Flames extends Guitar private String flame
Color; //constructor, getters và settersBằng cách mở rộng class Guitar, ta tất cả thể chắc hẳn rằng rằng áp dụng hiện có sẽ không còn bị tác động gì cả.

Giả sử Φ(x) là 1 trong những thuộc tính tất cả thể chứng tỏ được đối với các đối tượng x thuộc một số loại T. Lúc đó, Φ(y) phải bao gồm thể chứng minh được so với các đối tượng người tiêu dùng y thuộc các loại S mà trong các số ấy S là một trong những class con của T.

Nguyên tắc này tức là mọi class bé (subclass) hoặc class dẫn xuất phải có chức năng thay cố gắng cho class đại lý hoặc class thân phụ (superclass) của chúng mà ko làm tác động đến ứng dụng.

Trong 5 SOLID principles, nguyên tắc thay thế sửa chữa Liskov là hiệ tượng trừu tượng và nặng nề hiểu nhất. Chính vì thế, cố gắng vì phân tích và lý giải thêm, chúng ta cũng có thể hiểu nhanh bởi ví dụ sau:

Giả sử chúng ta có một class hình chữ nhật để tính diện tích s của một hình chữ nhật và tiến hành các hoạt động khác như khẳng định màu sắc:

class Rectangle set
Width(width) this.width = width; set
Height(height) this.height = height; set
Color(color) // ... get
Area() return this.width * this.height; Chúng ta gần như biết rằng tất cả các hình vuông là hình chữ nhật nên bạn có thể kế thừa những thuộc tính của hình chữ nhật. Bởi chiều rộng và chiều cao phải tương tự nhau, nên chúng ta cũng có thể điều chỉnh code như sau:

class Square extends Rectangle set
Width(width) this.width = width; this.height = width; set
Height(height) this.width = height; this.height = height; Nhìn vào ví dụ này, code nên chuyển động bình thường:

let rectangle = new Rectangle();rectangle.set
Width(10);rectangle.set
Height(5);console.log(rectangle.get
Area()); // 50Ở đoạn code trên, các bạn sẽ nhận thấy rằng một hình chữ nhật đã được tạo, và chiều rộng lớn và độ cao đã được xác định. Sau đó, bạn cũng có thể tính toán diện tích chính xác.

Tuy nhiên, theo nguyên tắc sửa chữa thay thế Liskov, các đối tượng người dùng của class nhỏ cần vận động giống như các đối tượng người tiêu dùng của class cha. Tức là nếu bạn thay thế sửa chữa hình chữ nhật bằng hình vuông, code vẫn nên vận động bình thường:

let square = new Square();square.set
Width(10);square.set
Height(5);Kết quả đáng lẽ ra bắt buộc là 100, cũng chính vì set
Width(10) yêu cầu cả độ cao và chiều rộng gần như là 10. Mặc dù nhiên, chính vì set
Height(5), nên kết quả sẽ là 25.

let square = new Square();square.set
Width(10);square.set
Height(5);console.log(square.get
Area()); // 25Tuy nhiên, vậy nên sẽ phá vỡ nguyên tắc thay thế Liskov. Để khắc chế lỗi này, chúng ta cần gồm một class tầm thường cho tất cả các kiểu dáng mà vẫn chứa tất cả các phương thức thông thường mà bạn có nhu cầu các đối tượng người tiêu dùng thuộc các class con truy vấn được. Sau đó, so với các cách thức riêng lẻ, chúng ta tạo một class riêng cho hình chữ nhật và hình vuông.

class Shape set
Color(color) this.color = color; get
Color() return this.color; class Rectangle extends Shape set
Width(width) this.width = width; set
Height(height) this.height = height; get
Area() return this.width * this.height; class Square extends Shape set
Side(side) this.side = side; get
Area() return this.side * this.side; Bằng bí quyết này, bạn cũng có thể đặt màu cùng lấy màu sắc bằng các class thân phụ hoặc class con:

// superclasslet shape = new Shape();shape.set
Color("red");console.log(shape.get
Color()); // đỏ// subclasslet rectangle = new Rectangle();rectangle.set
Color("red");console.log(rectangle.get
Color()); // đỏ// subclasslet square = new Square();square.set
Color("red");console.log(square.get
Color()); // đỏ

Một quý khách hàng không yêu cầu bị buộc phải thực hiện một giao diện mà người ta không sử dụng, hoặc phụ thuộc vào các phương pháp họ ko sử dụng.

Trong lấy một ví dụ này, bọn họ sẽ test “hóa thân” thành các người làm việc trong sở thú, ví dụ là vị trí quan tâm hổ.

Trước hết, hãy bước đầu với một interface dùng để làm liệt kê đông đảo đầu câu hỏi của một người âu yếm hổ.

public interface Tiger
Keeper void wash
The
Tiger(); void feed
The
Tiger(); void pet
The
Tiger();Là một người âu yếm thú năng nổ, họ sẵn sàng rửa mặt rửa và cho hổ ăn. Tuy nhiên, không phải ai cũng có đủ tài năng và lòng dũng cảm để “nựng” một chú hổ to đùng cả. Nhưng do interface của họ quá rộng, bắt buộc ta đề xuất phải tiến hành code nhằm “nựng” chú hổ ấy.

Chúng ta có thể sửa lỗi này bằng cách chia interface lớn thành tía interface riêng biệt:

public interface Tiger
Cleaner void wash
The
Tiger();public interface Tiger
Feeder void feed
The
Tiger();public interface Tiger
Petter void pet
The
Tiger();Giờ đây, nhờ tất cả sự phân bóc tách interface, ta có thể tự do thực thi chỉ các phương thức quan trọng đối với bọn chúng ta:

public class Tiger
Carer implements Tiger
Cleaner, Tiger
Feeder public void wash
The
Tiger() //Tắm rửa mà còn dơ! public void feed
The
Tiger() //Thứ 3 nạp năng lượng cá ngừ Và cuối cùng, chúng ta có thể nhường trọng trách “nựng” cho phần đông ai đầy đủ kỹ năng:

public class Skilled
Person implements Tiger
Petter public void pet
The
Tiger() //Cẩn thận các bạn nhé!

Các thực thể phải phụ thuộc vào abstraction, không phải class rõ ràng hay tính năng cụ thể.

Module v.i.p không được dựa vào vào module cung cấp thấp, nhưng lại chúng đều phải dựa vào vào abstraction.

Nói một cách đối chọi giản, hình thức Đảo ngược phụ thuộc nói rằng những class nên phụ thuộc vào interface hoặc abstraction cầm vì các class và tính năng cụ thể. Điều này làm cho các class mở rộng, tuân theo qui định Mở/đóng.

Xem thêm: Cách làm content facebook “cưa đổ” khách hàng, học 7 cách viết content facebook thu hút

Để lấy ví dụ cách vận dụng của chính sách này, hãy thuộc “hoài niệm” cùng với Windows 98:

public class Windows98Machine Nhưng làm sao một chiếc máy tính xách tay lại có thể không có screen và keyboard được? Hãy thêm nó vào constructor để phần đông Windows98Machine mà bọn họ khởi tạo đều có sẵn Monitor với một Standard
Keyboard:

public class Windows98Machine private final Standard
Keyboard keyboard; private final Monitor monitor; public Windows98Machine() monitor = new Monitor(); keyboard = new Standard
Keyboard(); Với code này, chúng ta có thể sử dụng Standard
Keyboard cùng Monitor thoải mái trong class Windows98Machine.

Tuy nhiên, bằng cách khai báo Standard
Keyboard cùng Monitor với tự khóa mới, chúng ta đã liên kết chặt chẽ ba class đó lại với nhau.

Điều này không chỉ làm cho Windows98Machine khó khám nghiệm mà bọn họ còn mất khả năng chuyển đổi class Standard
Keyboard bởi một lớp khác nếu có nhu cầu. Và bọn họ cũng không thể chuyển đổi class Monitor.

Hãy bóc tách Windows98Machine thoát ra khỏi Standard
Keyboard bằng cách thêm một interface Keyboard bao quát hơn và sử dụng interface này trong class:

public interface Keyboard public class Windows98Machine private final Keyboard keyboard; private final Monitor monitor; public Windows98Machine(Keyboard keyboard, Monitor monitor) this.keyboard = keyboard; this.monitor = monitor; Ở đây, họ đang áp dụng dependency injection pattern để thêm Keyboard dependency vào class Windows98Machine.

Chúng ta cũng hãy sửa thay đổi class Standard
Keyboard để triển khai giao diện Keyboard sao cho phù hợp để chuyển vào class Windows98Machine:

public class Standard
Keyboard implements Keyboard Bây giờ, các class đã được tách rời và giao tiếp thông qua Keyboard abstraction. Trường hợp muốn, chúng ta cũng có thể dễ dàng biến đổi loại keyboard trong máy bằng cách triển khai interface khác. Chúng ta cũng có thể làm theo nguyên tắc giống như cho class Monitor.

Giờ chúng ta đã tách rời các thành phần dựa vào và có thể tự vị kiểm Windows98Machine với ngẫu nhiên framework chất vấn nào.