Thuật ngữ (hoặc mô hình lồng tiếng?) Đối với nhóm Làm gì đó nếu chưa thực hiện được [đóng]

Nghe có vẻ khá cơ bản, tôi biết, nhưng gần đây tôi có một đồng nghiệp nói với tôi rằng một phương pháp được gọi startHttpServerlà quá phức tạp để hiểu bởi vì nó chỉ khởi động máy chủ nếu nó chưa chạy. Tôi thấy tôi gặp rắc rối khi trả lời, "Nghiêm túc sao? Tôi đã làm điều này trong nhiều thập kỷ - đó là một mô hình phổ biến trong lập trình." Thường xuyên hơn tôi quan tâm thừa nhận anh ta trở lại với một số bằng chứng tài liệu cho thấy rằng toàn bộ cộng đồng lập trình đứng sau quan điểm của anh ta và cuối cùng tôi cảm thấy ngượng ngùng.

Câu hỏi : Có một mẫu thiết kế tài liệu nào đằng sau khái niệm phương pháp là không có nếu hành động cần thiết đã có hiệu lực không? Hoặc, nếu không phải là một mẫu, nó cũng có một cái tên? Và nếu không, có lý do nào để nghĩ rằng nó quá phức tạp để xem xét viết một phương pháp theo cách này không?

Như NickWilliams đã nói : khái niệm mà OP mô tả được gọi là idempotent (danh từ Idempotency ). Đó thực sự là thực tế phổ biến, đặc biệt là trong các API cấp cao.

NHƯNG: Đổi tên chức năng.

Thay vì startHttpServergọi nó makeSureHttpServerIsRunninghay ensureHttpServerIsRunning.

Khi một chức năng được gọi startHttpServer, người đọc mong đợi nó sẽ khởi động máy chủ HTTP; Khi được gọi mười lần liên tiếp, tôi sẽ có mười máy chủ đang chạy. Chức năng của bạn không làm điều đó hầu hết thời gian. Ngoài ra, tên với "bắt đầu" gợi ý rằng nếu tôi chỉ muốn một máy chủ chạy, tôi sẽ phải theo dõi xem chức năng đã được gọi hay chưa.

Khi một hàm được gọi makeSureHttpServerIsRunning, tôi giả sử nó sẽ thực hiện những điều cần thiết để đảm bảo rằng máy chủ HTTP đang chạy, rất có thể bằng cách kiểm tra xem nó có đang chạy hay không và khởi động nó theo cách khác. Tôi cũng giả định rằng chức năng này đảm bảo rằng máy chủ đang thực sự chạy (bắt đầu một máy chủ có thể liên quan đến một số thời điểm mà nó chưa hoàn toàn chạy).

Đổi tên nó thành EnsureServerRunning.

Hoàn toàn rõ ràng và rõ ràng rằng nó đảm bảo rằng nó đang chạy (nếu không) mà không ngụ ý khởi động lại nếu có.

(Thay thế : StartServerIfNotRunning?)

Không thực sự là một mẫu thiết kế nhưng tôi sẽ gọi phương thức của bạn là idempotent . Có thuật ngữ thường được sử dụng để chỉ các cuộc gọi từ xa nhưng mô tả có vẻ phù hợp với những gì bạn đang làm.

Phương pháp tạm thời. Các phương thức cũng có thể có thuộc tính "idempotence" trong đó (ngoài các vấn đề lỗi hoặc hết hạn), các tác dụng phụ của N> 0 yêu cầu giống hệt như đối với một yêu cầu. ( Từ W3.org )

Tác dụng phụ của máy chủ ở đây là máy chủ http được khởi động sau khi phương thức được gọi. Tôi thấy không có gì sai với một phương pháp làm điều này.

Nếu bạn cần một mẫu thiết kế, tôi đoán bạn có thể hiển thị httpServer của mình dưới dạng một singleton được bắt đầu khi khởi tạo.

Là một trong những người thực hiện điều này công cụ , startHttpServerbạn cần phải cố gắng để làm cho nó đơn giản nhất, trơn tru và liền mạch để sử dụng ...

Logic của hàm

Về mặt kỹ thuật, bằng cách tách startHttpServer's logic vào 2 chức năng và gọi họ riêng biệt , tất cả những gì bạn làm là di chuyển startHttpServer ' s idempotency vào mã gọi cả hai chức năng thay vì ... Hơn nữa, trừ khi bạn quấn cả logic trong một chức năng thứ ba (đó là những gì hiện startHttpServerở vị trí đầu tiên), điều này buộc bạn phải viết mã chưa được mã hóa, sao chép nó theo cấp số nhân ở mọi nơi bạn phải gọi startHttpServer. Tóm lại, startHttpServer phải gọi chính nó là isHttpServerRunningchức năng.

Vì vậy, quan điểm của tôi là:

• Thực hiện isHttpServerRunningchức năng bởi vì điều này có thể cần thiết một cách độc lập ...
• Triển khai startHttpServerlàm cho nó sử dụng isHttpServerRunningđể xác định hành động tiếp theo của nó phù hợp ...

Tuy nhiên, bạn có thể startHttpServertrả về bất kỳ giá trị nào mà người dùng của chức năng này có thể cần, ví dụ:

• 0 => máy chủ bắt đầu thất bại
• 1 => máy chủ bắt đầu thành công
• 2 => máy chủ đã được khởi động rồi

Chức năng đặt tên

Trước hết, mục tiêu chính của người dùng là gì? Để khởi động máy chủ HTTP , phải không?

Về cơ bản, không có vấn đề gì bằng cách dự định bắt đầu một cái gì đó đã được bắt đầu, AKA 1*1=1. Vì vậy, ít nhất với tôi, gọi nó là " ensureHttpServerIsRunning" dường như không cần thiết lắm, tôi quan tâm nhiều hơn đến việc tên của hàm dài bao nhiêu, tự nhiên và đáng nhớ.

Bây giờ nếu bạn muốn biết làm thế nào để làm việc chi tiết chức năng dưới mui xe, có tài liệu hoặc nguồn mã cho điều đó, ý tôi là giống như bất kỳ chức năng nào khác từ thư viện / framework / API / vv ...

Bạn học hàm một lần trong khi bạn viết nó nhiều lần ...

Vì vậy, dù sao, tôi sẽ gắn bó với startHttpServercái ngắn hơn, đơn giản hơn và rõ ràng hơn ensureHttpServerIsRunning.

Tôi cho rằng đồng nghiệp của bạn có nghĩa startHttpServerlà đang làm quá nhiều:

• Kiểm tra xem máy chủ đã chạy chưa,
• Khởi động máy chủ nếu cần.

Đó là hai phần không liên quan của mã. Chẳng hạn, một tình huống tương tự tồn tại khi một ứng dụng máy tính để bàn phải đảm bảo rằng nó chưa chạy khi được khởi chạy; sẽ có một phần mã xử lý các trường hợp ứng dụng (ví dụ sử dụng mutex) và mã sẽ bắt đầu vòng lặp thông báo ứng dụng.

Điều này có nghĩa là bạn không phải có một, mà ít nhất là hai phương thức :

• isHttpServerRunning: boolean
• startHttpServer

Điểm vào ứng dụng sẽ gọi phương thức đầu tiên, và sau đó là phương thức thứ hai nếu giá trị trả về là false. Bây giờ, mọi phương pháp đang làm một và một điều, và rất dễ hiểu.

^{¹ Nếu logic cần biết nếu máy chủ đang chạy quá phức tạp, nó có thể yêu cầu phân tách thành nhiều phương thức.}

Vì bạn không chỉ định ngôn ngữ, trong JavaScript, nhiều thư viện có chức năng "một lần", ví dụ như gạch dưới . Vì vậy, nếu điều đó quen thuộc với bạn, hãy gọi nó là mẫu "một lần" và có thể đổi tên phương thức của bạn.

Bản thân tôi, đến nhiều hơn từ Java, các thuật ngữ "bộ nhớ đệm" hoặc "đánh giá lười biếng" xuất hiện trong tâm trí. "Idempotent" là đúng về mặt kỹ thuật và là một lựa chọn tốt, đặc biệt. nếu bạn có một nền tảng chức năng hơn.

Tôi thích hơn startHttpServerIfNotIsRunning.

Bằng cách này, điều kiện được đề cập rõ ràng đã có trong tên phương thức. Ensurehoặc makeSurecó vẻ hơi mơ hồ với tôi, vì nó không phải là một biểu hiện kỹ thuật. Có vẻ như chúng ta không biết chính xác những gì sẽ xảy ra.

Điều mà đồng nghiệp của bạn nên nói với bạn là bạn không có kinh doanh viết phương pháp đó. Nó đã được viết rất nhiều lần và được viết tốt hơn khả năng bạn viết nó. Ví dụ: http://docs.ansible.com/ansible/latest/systemd_module.html https://docs.saltstack.com/en/latest/ref/states/all/salt.states.service.html

Từ góc độ kiến ​​trúc, có một chút mã tùy ý quản lý máy chủ web là công cụ của những cơn ác mộng. Trừ khi quản lý dịch vụ là độc quyền những gì mã của bạn làm. Nhưng tôi đoán bạn đã không viết monit (hoặc kubernetes hoặc ...).