CFSDN nhấn mạnh vào giá trị tạo ra nguồn mở và chúng tôi cam kết xây dựng nền tảng chia sẻ tài nguyên để mọi nhân viên CNTT có thể tìm thấy thế giới tuyệt vời của bạn tại đây.
Bài viết blog CFSDN này Trò chuyện PHP "Tái cấu trúc - Cải thiện thiết kế mã hiện có" Phần 4 đơn giản hóa các biểu thức điều kiện được tác giả sưu tầm và biên soạn. Nếu bạn quan tâm đến bài viết này, hãy nhớ thích nó.
bản đồ tư duy
Nhấp vào hình ảnh bên dưới để xem phiên bản lớn hơn.

giới thiệu
Logic có điều kiện có thể rất phức tạp, vì vậy chương này cung cấp một số kỹ thuật tái cấu trúc được thiết kế đặc biệt để đơn giản hóa chúng.
Mô tả ngắn gọn toàn văn(Bạn có thể bỏ qua trực tiếp nội dung sau)
Tái cấu trúc cốt lõi: Phân tách có điều kiện - Tách biệt "logic chuyển đổi" và "chi tiết hoạt động".
Nhiều bài kiểm tra có cùng một kết quả: Hợp nhất biểu thức có điều kiện
Xóa các thành phần trùng lặp khỏi mã có điều kiện: Hợp nhất trùng lặp
Xác định các điều kiện đặc biệt: Thay thế Điều kiện lồng nhau bằng Điều khoản bảo vệ
Xóa cờ kiểm soát gây phiền nhiễu: Xóa cờ kiểm soát
Thuật ngữ chuyên môn
phân hủy: phân hủy, tách ra
hợp nhất: hợp nhất
đủ điều kiện: phù hợp, đủ điều kiện
mảnh: mảnh, mảnh
tổ: làm tổ
bảo vệ: phòng thủ
mệnh đề: mệnh đề
đa hình: đa hình
khẳng định: khẳng định
ngoại lệ không được kiểm soát: ngoại lệ không thể kiểm soát
Phân tích điều kiện
tình huống:Bạn có một câu lệnh có điều kiện phức tạp (if-else if-else), sau đó
Trích xuất các hàm từ ba đoạn văn if, else if và else.



。
。

。
Hợp nhất biểu thức điều kiện
tình huống:Bạn có một số bài kiểm tra có điều kiện mà tất cả đều nhận được kết quả như nhau, sau đó
Kết hợp các phép thử này thành một biểu thức điều kiện và tinh chỉnh điều kiện này thành một hàm riêng biệt.
động lực: 1. Mã điều kiện được hợp nhất sẽ cho bạn biết "thực ra chỉ có một điều kiện kiểm tra, nhưng có một số điều kiện song song cần được kiểm tra" - làm cho mục đích của việc kiểm tra trở nên rõ ràng hơn.
2. Chuẩn bị cho phương pháp chiết xuất. --Việc tinh chỉnh điều kiện kiểm tra thành một hàm độc lập rất hữu ích để làm rõ ý nghĩa của mã. Nó thay thế câu mô tả “phải làm gì” bằng “tại sao phải làm điều đó”.





。
“Lý do hợp nhất” của câu điều kiện cũng chỉ ra lý do “không hợp nhất”: Nếu bạn cho rằng những séc này của bạn thực sự độc lập với nhau và không nên coi là cùng một séc thì đừng sử dụng việc tái cấu trúc này. Bởi vì trong trường hợp này, code của bạn đã thể hiện rõ ràng ý nghĩa của nó.
。

。
Hợp nhất các đoạn điều kiện trùng lặp
tình huống:Có cùng một đoạn mã trên mỗi nhánh của biểu thức điều kiện, sau đó
Di chuyển mã lặp đi lặp lại này ra ngoài điều kiện.
Xóa cờ điều khiển
tình huống:Trong một chuỗi các biểu thức Boolean, một biến có chức năng là “dấu điều khiển”, khi đó
Thay thế thẻ điều khiển bằng câu lệnh break hoặc câu lệnh return.
Thay thế Điều kiện lồng nhau bằng Mệnh đề bảo vệ
tình huống:Logic điều kiện trong hàm khiến cho việc nhìn thấy đường dẫn thực thi thông thường trở nên khó khăn, do đó
Sử dụng các mệnh đề bảo vệ để diễn đạt tất cả các trường hợp đặc biệt.
Hai dạng biểu thức điều kiện:
1. Tất cả các nhánh đều hoạt động bình thường: sử dụng [if ... else..]
2. Biểu thức điều kiện cực kỳ hiếm: điều kiện phải được kiểm tra riêng biệt và được trả về từ hàm ngay lập tức khi điều kiện là đúng. --Những kiểm tra cá nhân như vậy thường được gọi là "tuyên bố bảo vệ".
Bản chất của Thay thế Điều kiện lồng nhau bằng Điều khoản bảo vệ: Đặc biệt chú ý đến một nhánh nhất định.
Thay thế điều kiện bằng đa hình
tình huống:Bạn có một biểu thức trong tay để chọn các hành vi khác nhau tùy thuộc vào loại đối tượng, sau đó
Đặt từng nhánh của biểu thức điều kiện này vào một hàm được ghi đè trong một lớp con, sau đó khai báo hàm ban đầu là một hàm trừu tượng.

Mùi hôi của mã này:
1. Video quá dài khi có kiểu mới sẽ dài hơn.
2. Rõ ràng nó làm được nhiều việc.
3. Nó vi phạm nguyên tắc trách nhiệm duy nhất vì nó có nhiều lý do để sửa đổi.
4. Nó vi phạm nguyên tắc đóng mở vì nó phải được sửa đổi bất cứ khi nào một loại mới được thêm vào. Nhưng có lẽ điều rắc rối nhất là có những hàm tương tự như cấu trúc (_lấy tên kiểu Rank()) ở khắp mọi nơi.



Giới thiệu Khẳng định
tình huống:Một đoạn mã nhất định cần đưa ra một số giả định về trạng thái chương trình, sau đó
Thể hiện giả định này một cách rõ ràng bằng một khẳng định.
。

Kết quả chạy:

Điểm chọn:
1. Thường có mã như thế này. Mã này chỉ có thể chạy bình thường khi một điều kiện nào đó đúng. ---Trên thực tế, sản phẩm cuối cùng của chương trình thường xóa tất cả các xác nhận.
2. Những giả định như vậy thường không được thể hiện rõ ràng trong mã. Bạn phải đọc toàn bộ thuật toán để xem nó. - Đôi khi các lập trình viên viết những giả định như vậy dưới dạng nhận xét, nhưng khẳng định là một kỹ thuật tốt hơn.
3. khẳng định là một biểu thức có điều kiện và phải luôn đúng. Nếu thất bại, điều đó có nghĩa là
Lập trình viên đã mắc lỗi。
4. khẳng định có thể được sử dụng như
Giao tiếp và gỡ lỗiphụ trợ. ---Giao tiếp: Có thể giúp lập trình viên đọc và hiểu các giả định mà mã đưa ra. Gỡ lỗi: Giúp lập trình viên tìm ra lỗi và bắt chúng ở vị trí gần nhất.
5、
Các xác nhận không thay đổi bất kỳ hành vi nào của chương trình.
6、
Giá trị xác nhận: Giúp người lập trình hiểu được các điều kiện cần thiết để mã chạy chính xác.
7. Nên sử dụng Phương pháp trích xuất cho biểu thức điều kiện của xác nhận, để trích xuất các mã lặp lại ở nhiều vị trí vào cùng một hàm, có lẽ chỉ để giải thích mục đích của biểu thức điều kiện rõ ràng hơn.
Tóm tắt
Tôi thích phương pháp "Thay thế các điều khoản lồng nhau bằng các điều khoản bảo vệ" trong chương này. Tôi thường sử dụng phương pháp này trong mã hàng ngày của mình. Một số người còn gọi phương pháp này là "Các điều khoản bảo vệ".
Một điều nữa là tôi thường sử dụng var_dump() hoặc print_r() để gỡ lỗi trong quá trình phát triển PHP. Đây là lần đầu tiên tôi phát hiện ra rằng có một phương thức khẳng định trong PHP, điều này thật tốt!
Trong quá trình học tập và thực hành tôi cũng học được nhiều phương pháp hay. Nhưng tôi nghĩ trong quá trình phát triển nhóm, đôi khi "tình hình chung là quan trọng nhất", viết mã theo cách thông thường của nhóm hoặc bạn có thể giao tiếp với nhóm và sau khi được sự đồng ý của mọi người, hãy sử dụng các phương pháp ở đây để mọi người có thể gỡ lỗi lẫn nhau Sẽ thuận tiện hơn khi đọc mã của nhau.
Cuối cùng, bài viết về việc đơn giản hóa các biểu thức điều kiện trong Phần 4 của Thảo luận PHP "Tái cấu trúc - Cải thiện thiết kế mã hiện có" kết thúc tại đây. Nếu bạn muốn biết thêm về Thảo luận PHP "Tái cấu trúc - Cải thiện thiết kế mã hiện có" 》Phần 4: Về nội dung các biểu thức điều kiện đơn giản, vui lòng tìm kiếm các bài viết của CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .
Tôi là một lập trình viên xuất sắc, rất giỏi!