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 5 đơn giản hóa các lệnh gọi hàm đượ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ó.

Sơ đồ tư duy giới thiệu một số bài viết đầu tiên trong loạt bài này. Tôi quan tâm nhiều hơn đến , nhưng tôi cảm thấy mình vẫn chưa nói rõ. Bản thân tôi cũng có nhiều chỗ chưa hiểu và đây là bài viết đầu tiên của tôi về lĩnh vực này còn nhiều sai sót nên tôi sẽ sửa đổi thường xuyên nếu có ý kiến ​​hay xin vui lòng cho tôi biết. 2. Hôm nay chúng ta đang nói về "giao diện". Giao diện này không phải là "Giao diện", mà là một thuật ngữ chung. Nói chung, chúng ta có thể gọi các hàm hoặc URL để người khác sử dụng (thường được sử dụng để cung cấp dữ liệu) làm giao diện. ---Có thể còn có ý nghĩa khác, tôi vẫn là "tân binh". Nếu có sai sót nào trong cách hiểu, xin hãy sửa lại cho tôi. Chúng tôi biết rằng "giao diện dễ hiểu và dễ sử dụng" là chìa khóa để phát triển phần mềm hướng đối tượng tốt. ---Bài viết này sẽ giới thiệu phương pháp xây dựng lại "làm cho giao diện đơn giản và dễ sử dụng hơn". Lạc đề: Nếu bạn cho rằng bài viết của tôi quá dài và có vẻ rắc rối, tôi khuyên bạn "chỉ cần nhìn vào hình ảnh và dòng chữ in đậm". Hôm qua có một blogger “cũ” để lại cho tôi một tin nhắn trước đây tôi chưa bao giờ suy nghĩ kỹ, nhưng lần này tôi cũng nghĩ đến. Nội dung tin nhắn là: .

Cá nhân tôi cảm thấy rằng chúng ta chỉ có thể biết giá trị của nhiều thứ nếu chúng ta chú ý đến chúng. Còn để đơn giản thì mục đích của việc tái cấu trúc cũng là để đơn giản, dễ hiểu. Còn về sự kiên trì, tôi nghĩ trong công nghệ, chúng ta thường cần kiểu kiên trì này. Ngay cả khi sau này bạn cho rằng mình đã sai, chúng ta vẫn sẽ đạt được điều gì đó trong lúc đó. Chỉ sau khi trải qua nhiều lần chạy vào (cả đúng và sai) chúng ta mới biết được giá trị của nó và đạt được điều mình cần. Về lợi ích, "Cũ" có phải là lợi ích của công ty không? Vâng, nhiều khi chúng ta cần bắt kịp trong quá trình viết mã và chúng ta cũng sẽ mắc một số sai lầm trong quá trình tái thiết, vì vậy gợi ý của tôi là, Khi bắt đầu. phát triển, bạn phải liên tục điều chỉnh trong quá trình thiết kế và xây dựng lại. Đừng cảm thấy lãng phí thời gian. Trong nhiều trường hợp, một cấu trúc tốt có thể đẩy nhanh tốc độ phát triển của bạn. Thuật ngữ chuyên nghiệp.

  。

Đổi tên Phương thức Điều kiện: Sửa đổi tên hàm nếu nó không tiết lộ mục đích của hàm. .

Động lực: Một phong cách lập trình mà tôi hết sức ủng hộ là chia các quy trình phức tạp thành các hàm nhỏ. Nhưng nếu việc đặt tên cho các hàm nhỏ không tốt sẽ khiến bạn phải loay hoay tìm hiểu mục đích của từng hàm nhỏ này. Cách đặt tên hàm hay: Hãy nghĩ xem nên viết chú thích gì cho hàm này --> Tìm cách chuyển chú thích thành tên của hàm. Để có được một cái tên hay không phải là điều dễ dàng và cần có kinh nghiệm. ——Nếu bạn muốn trở thành một bậc thầy lập trình thực thụ thì trình độ “đặt tên” là rất quan trọng. Nếu bạn thấy tên hàm không truyền tải tốt mục đích của nó thì bạn nên thay đổi nó ngay lập tức. Ví dụ: .

Tình huống Thêm tham số: Hàm cần lấy thêm thông tin từ đầu gọi, vì vậy, hãy thêm tham số vào hàm và để tham số mang lại thông tin mà hàm yêu cầu. Động lực: 1. Thêm tham số là một kỹ thuật tái cấu trúc rất phổ biến. 2. Hàm được sửa đổi yêu cầu một số thông tin trước đây không có, vì vậy bạn cần thêm tham số vào hàm. 3. Ngoại trừ Thêm Tham số, bất cứ khi nào có thể, các tùy chọn khác sẽ tốt hơn "Thêm Tham số" vì có thể các tùy chọn khác sẽ không tăng độ dài của cột tham số. --Danh sách tham số quá dài sẽ khiến người lập trình khó nhớ được nhiều tham số như vậy. .

Tình huống xóa tham số: Thân hàm không cần tham số nữa nên hãy xóa tham số. Động lực: 1. Các tham số chỉ ra thông tin chức năng, các tham số khác nhau thể hiện ý nghĩa khác nhau. Cuộc gọi hàm phải lo lắng về những gì cần truyền vào cho từng tham số. ——Nếu không loại bỏ các thông số, bạn sẽ phải chú ý hơn đến từng cuộc gọi. 2. Nếu bạn thấy có nhiều người gọi, để không khiến người gọi lo lắng, bạn có thể thực hiện việc này và đặt các tham số cần xóa thành giá trị mặc định (chẳng hạn như null), để người gọi chỉ chuyển những tham số đó không có tham số mặc định. .

Tách truy vấn khỏi trình sửa đổi.

  。

Tình huống: Nếu một hàm vừa trả về giá trị trạng thái của đối tượng vừa sửa đổi (như một tác dụng phụ) trạng thái của đối tượng, thì hãy tạo hai hàm khác nhau, một hàm chịu trách nhiệm truy vấn và hàm kia chịu trách nhiệm sửa đổi.

  。

 Phương pháp tham số hóa 。

  。

Tình huống: Nếu một số hàm thực hiện công việc tương tự nhưng chứa các giá trị khác nhau trong nội dung hàm, hãy tạo một hàm duy nhất biểu thị các giá trị khác nhau đó dưới dạng tham số.

động lực:

　　1. Nói chung, một số hàm tương tự được tạo ra vì có một số giá trị khác nhau.

　　2. Thay thế các hàm riêng biệt bằng một hàm thống nhất và xử lý những thay đổi đó thông qua các tham số để đơn giản hóa bài toán.

　　3. Loại bỏ mã trùng lặp và cải thiện tính linh hoạt. --Bạn có thể sử dụng tham số này để xử lý các thay đổi khác.

  。

Ví dụ:

  。

 Thay thế tham số bằng phương pháp rõ ràng.

  。

Tình huống: Bạn có một hàm hoạt động khác nhau tùy thuộc vào giá trị của tham số. Tạo một hàm riêng cho từng giá trị của tham số.

động lực:

　　1. Nếu một tham số có các giá trị rời rạc và các giá trị tham số này được kiểm tra có điều kiện trong hàm và các phản hồi khác nhau được thực hiện dựa trên các giá trị tham số khác nhau, thì nên sử dụng cấu trúc lại này.

　　2. Lợi ích có thể nhận được: "kiểm tra mã thời gian biên dịch", "giao diện rõ ràng hơn" (nếu các giá trị tham số được sử dụng để xác định hành vi của hàm, thì người dùng hàm không chỉ cần quan sát hàm mà còn phải xác định xem các tham số có "hợp pháp hóa". - Và các thông số pháp lý hiếm khi được đề cập trong tài liệu và phải được đánh giá thông qua ngữ cảnh).

　　3. Bất kể lợi ích của việc "kiểm tra thời gian biên dịch", để có được giao diện rõ ràng, chúng ta nên làm như vậy.

Ví dụ

  。

 Bảo toàn toàn bộ đối tượng 。

  。

Tình huống: Nếu bạn lấy một số giá trị từ một đối tượng và sử dụng chúng làm tham số trong lệnh gọi hàm, thì thay vào đó hãy sử dụng (truyền) toàn bộ đối tượng.

 động lực:

　　1. Danh sách tham số ổn định hơn,

　　2. Cải thiện khả năng đọc mã; - danh sách tham số quá dài sẽ khó sử dụng, vì cả người gọi và người được gọi đều phải nhớ mục đích của các tham số này.

Ví dụ:

  。

 Thay thế tham số bằng phương pháp 。

  。

Tình huống: Nếu đối tượng gọi một hàm và truyền kết quả dưới dạng tham số cho hàm khác (hàm nhận tham số cũng có khả năng gọi hàm trước đó) thì để người nhận tham số loại bỏ tham số và gọi trực tiếp hàm trước đó một hàm.

  。

động lực:

　　1. Nếu hàm lấy giá trị tham số thông qua các phương tiện khác thì nó sẽ không lấy giá trị thông qua tham số.

　　2. Danh sách tham số quá dài sẽ làm tăng độ khó hiểu của người đọc chương trình, vì vậy chúng ta nên rút ngắn độ dài của danh sách tham số càng nhiều càng tốt.

　　3. Phương pháp: Xem liệu "đầu nhận tham số" có thể lấy giá trị mang tham số thông qua "phép tính tương tự như đầu cuối gọi" hay không.

　　4. Nếu đầu gọi hàm tính toán các tham số thông qua một hàm khác bên trong đối tượng và "không có tham số nào khác của đầu gọi được tham chiếu" trong quá trình tính toán, thì quá trình tính toán có thể được chuyển sang đầu được gọi, từ đó loại bỏ tham số .

  。

Ví dụ:

  。

 Giới thiệu đối tượng tham số 。

  。

Tình huống: Một số tham số nhất định luôn xuất hiện cùng nhau một cách tự nhiên, vì vậy hãy thay thế các tham số này bằng một đối tượng.

  。

động lực:

　　1. Một tập hợp các tham số có thể được sử dụng bởi nhiều hàm cùng một lúc. Các hàm này có thể thuộc cùng một lớp hoặc thuộc các lớp khác nhau. ---Tập hợp các tham số như vậy được gọi là Cụm dữ liệu.

　　2. Chúng ta có thể sử dụng một đối tượng để bao bọc tất cả dữ liệu này, sau đó thay thế Cụm dữ liệu bằng đối tượng. --Mục đích: Ngay cả khi chỉ để sắp xếp các dữ liệu này lại với nhau thì cũng đáng giá.

　　3. Giá trị của việc tái cấu trúc này nằm ở việc “rút ngắn độ dài của cột tham số”. Ngoài ra, các trình truy cập được xác định bởi đối tượng mới có thể làm cho mã nhất quán hơn. --Điều này càng làm giảm bớt khó khăn trong việc hiểu và sửa đổi mã.

　　4. Việc tái thiết này cũng có thể mang lại cho bạn nhiều lợi ích hơn. --Khi bạn sắp xếp các tham số này lại với nhau, bạn thường có thể nhanh chóng phát hiện ra hành vi của "lớp mới di động". --Giảm mã trùng lặp.

  。

Ví dụ:

  。

 Phương pháp xóa cài đặt 。

  。

Tình huống: Một trường giá trị nhất định trong lớp của bạn phải được đặt khi đối tượng được tạo và sau đó không bao giờ thay đổi. Sau đó, hãy xóa tất cả các bộ cài đặt cho trường giá trị này.

động lực:

　　1. Nếu bạn cung cấp bộ cài đặt cho một phạm vi, điều đó có nghĩa là phạm vi đó có thể được thay đổi.

　　2. Nếu bạn không muốn phạm vi giá trị này thay đổi sau khi đối tượng được tạo thì đừng cung cấp chức năng cài đặt cho nó. ---Bằng cách này, ý định của bạn sẽ rõ ràng hơn và bạn có thể loại trừ khả năng giá trị của nó bị sửa đổi.

Ví dụ:

  。

 Phương pháp ẩn 。

  。

Tình huống: Nếu có một hàm chưa từng được các lớp khác sử dụng thì hãy đặt hàm này thành riêng tư.

  。

động lực:

　　1. Việc tái cấu trúc thường nhắc bạn sửa đổi "khả năng hiển thị của các hàm". --Luôn kiểm tra các chức năng có thể bị ẩn.

　　  2. Luôn kiểm tra xem có thể giảm mức độ hiển thị của một chức năng hay không (đặt nó ở chế độ riêng tư).

　　　　-->Khi bạn xóa lệnh gọi đến một hàm ở lớp khác, bạn nên kiểm tra.

　　　　-->Đặc biệt thực hiện các kiểm tra trên đối với hàm setter.

  。

　　

  。

 Thay thế Mã lỗi bằng Ngoại lệ 。

  。

Điều kiện: Nếu một hàm trả về một mã đặc biệt để biểu thị tình trạng lỗi, thay vào đó hãy sử dụng Ngoại lệ.

  。

động lực:

　　Sự tách biệt rõ ràng giữa "chương trình bình thường" và "xử lý lỗi" giúp chương trình dễ "hiểu" hơn.

Ví dụ:

  。

 Phần kết luận .

  。

Tôi muốn chia sẻ mỗi vụ thu hoạch của tôi với bạn. Nếu bạn kiếm được dù chỉ một chút, tôi sẽ rất vui. Ngoài ra, nếu bài viết có sai sót gì xin vui lòng cho tôi một số gợi ý 1 và 2.

  。

Tôi không biết mình có tìm nhầm chỗ không. Một số blogger đã để lại thông báo rằng “C# chủ yếu phổ biến trong cộng đồng blog”. Có lẽ mọi người chủ yếu là lập trình viên PHP? Vẫn còn rất ít người để lại tin nhắn cho tôi và rất ít người chỉ ra những sai sót trong bài viết của tôi (thực sự không có lỗi nào trong bài viết của tôi sao?). Hôm qua, "@四EYED Masked Man" đã để lại cho tôi một tin nhắn. rất nhiều từ việc nói chuyện với anh ấy, và tôi biết ơn những lời chỉ trích và sửa chữa của anh ấy. Tôi hy vọng được giao tiếp nhiều hơn với mọi người.

Cuối cùng, bài viết về việc đơn giản hóa lệnh gọi hàm trong Phần 5 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ó" 5. Đối với nội dung các lệnh gọi hàm được đơn giản hóa, 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! .