返回計算結果和狀態。最佳實踐

我思考模式，允許我回到這兩個計算結果和狀態：返回計算結果和狀態。最佳實踐

有，我能想到的幾種方法：

函數返回計算結果，正在返回的狀態通過參數（不是所有的語言都支持參數，這看起來是錯誤的，因爲一般來說你不希望參數被修改）。（缺點是你必須創建仿真類來返回函數結果或使用沒有語義含義的對 - 你知道哪個參數是它的順序）。
如果你的狀態就是成功/失敗就可以返回計算值，並在錯誤的情況下拋出異常（看起來像最好的方法，但只有成功/失敗情況的工作，不應該被濫用控制正常的程序流程）。
函數返回值，函數參數委託給onSuccess/onFailure過程。
有一個（state-full）方法類有狀態字段，並且方法返回計算結果（我更喜歡有無狀態/不可變對象）。

請給我利弊和情況使用上述方法或告訴我，我可以使用（最好帶提示的先決條件時使用它們）其他模式的先決條件的提示。

編輯：真實的例子：我開發的Java EE互聯網應用，我有一類解析請求參數字符串轉換爲他們的一些業務邏輯對象。解析器正在檢查db是否正在創建或編輯對象，然後向控制器返回從db中獲取的新對象或對象。控制器根據從解析器讀取的對象狀態（新/編輯）採取行動。我知道這很糟糕，我想在這裏改進代碼設計。

來源

2011-12-13 0lukasz0

在C和C++中，至少完全可以擁有out參數。所以我通常通過返回值返回成功/失敗，並修改一個輸出參數以反映計算輸出。這也允許在動態分配內存的情況下更好的資源控制。 – arne

有很多缺點和專業的，但我想知道這個問題是否會保持開放，因爲它看起來對我來說是類似於http://stackoverflow.com/questions/36707/should-a-function-have-只有一個回報陳述問題。我希望它保持開放，我認爲這些問題完全符合本網站的內容。 –

我認爲其他問題與此完全不同。這是關於在代碼中使用多個return語句，而不是返回多個「結果」。另外我發現這個：http://stackoverflow.com/questions/4181018/what-is-the-pros-and-cons-of-using-out-parameter作爲一個關於out參數的非常好的討論，它涵蓋了第一個提到的方法。 – 0lukasz0

函數返回計算結果，正在通過了參數返回的狀態（不是所有的語言都支持輸出參數，這似乎錯誤的，因爲一般你不要指望參數進行修改）。

如果語言支持多個輸出值，那麼語言顯然是支持它們的。這是一個恥辱，不使用它們（除非有強烈的意見，在特定的社區對他們 - 這可能是語言的情況下，嘗試和做一切）

函數返回對象/缺點是你必須創建人工類只是爲了返回函數結果或使用對沒有語義含義 - 你知道哪個參數是它的順序）。

我不知道那個缺點。在我看來，名爲「MyMethodResult」的記錄或類本身應該有足夠的語義。你總是可以在例外情況下使用這樣的課程，如果你當時只處於特殊狀態。根據我的觀點，創建某種陣列/聯合/對將不太可以接受：您將不可避免地在某處丟失信息。

如果你的狀態就是成功/失敗就可以返回計算值，並在錯誤的情況下拋出異常（看起來像最好的的辦法，但只有成功/失敗的情況下工作和不應該被濫用來控制正常的程序流程）。

不！這是最糟糕的做法。例外情況應該用於確切的情況。否則，他們將停止調試程序，將同事放在錯誤的腳上，損害性能，填寫日誌記錄系統並調試單元測試。如果你創建了一個方法來測試一些東西，那麼測試應該返回一個狀態，而不是一個例外：對於執行，返回一個負值是而不是例外。當然，如果你在解析過程中用完了一個文件中的字節，肯定會引發異常，但是如果輸入不正確，並且你的方法被稱爲checkFile，就不要拋出異常。

函數返回值，函數參數委託給 onSuccess/onFailure程序。

我只會使用那些如果你有多個結果共享。它比班級/記錄方式更爲複雜，而且更難維護。我使用這種方法返回多個結果，但我不知道結果是否被忽略，或者用戶是否想要繼續。在Java中你會使用一個監聽器。這種操作可能更多地被功能語言所接受。

有具有狀態字段（狀態完整）方法的類，和方法返回計算結果（我更喜歡具有無狀態/不可變的對象）。

是的，我更喜歡那些。有結果的生產者和結果本身。幾乎沒有必要將這兩者結合起來並創建一個有狀態的對象。

最後，你想要去producer.produceFrom（x）：結果在我看來。如果我的計數正確，這可以是選項1或2a。是的，對於2a，這意味着寫一些額外的代碼。

來源

2011-12-31 00:08:48

Mods，我試圖以客觀的方式回答這個問題，通過引入參數。漂亮，請不要在這裏有戰爭般的維基百科，讓適度的人爲你做好工作。如果它的有用性和主題，它應該*留*。 –

感謝您在本次討論中的輸入。我給+1，雖然有一些我不完全同意你的陳述。首先，我不認爲out參數是非常好的選擇。它們可能非常混亂，並且很容易忽略使用out參數的函數的可能副作用。我同意2a似乎是非常強大的選擇，只要你的代碼保持DRY，額外的代碼在這裏沒有錯。此外，您提出了一個很好的觀點，提到回調場景中增加了複雜性。我們都同意，異常只應用於故障情況。 – 0lukasz0

我並不特別喜歡輸出參數。但是，如果編程語言被明確寫入使用輸出參數（並且它們用於例如標準庫），那麼我認爲您不應該忽視它們作爲程序員。程序員應該嘗試並適應編程環境，否則代碼將成爲編程風格的大雜燴。 –

我的傾向是要麼使用out參數，要麼使用「open-field」結構，它只包含公共字段並指定其目的僅僅是攜帶這些字段的值。儘管有些人認爲所有東西都應該被「封裝」，但我會建議如果計算自然會產生兩個稱爲Moe和Larry係數的值，則指定該函數應該返回「帶有double類型字段的普通舊數據結構稱爲MoeCoefficient和LarryCoefficient「將用於完全定義結構的行爲。雖然結構必須在執行計算的方法之外被聲明爲數據類型，但將其內容作爲公共字段公開會清楚地表明與這些值關聯的語義都不包含在結構中 - 它們都是包含在返回它的方法中。

有些人會爭辯說，結構應該是不可變的，或者它應該在其構造函數中包含驗證邏輯等，我會建議相反。如果結構的目的是允許一個方法返回一組值，那麼該方法的責任應該是確保它將適當的值放入結構中。此外，雖然將構造函數暴露爲「便利成員」的結構沒有什麼問題，但是單獨將代碼分別返回結構體填充的代碼可能比調用構造函數更快更清晰，特別是如果要存儲的值在一個字段中取決於存儲在另一個字段中的值。

如果一個結構只是暴露其領域公開，那麼語義是很清楚的：MoeCoefficient包含已寫入MoeCoefficient的最後一個值，並LarryCoefficient包含寫入LarryCoefficient的最後一個值。這些值的含義完全取決於編寫它們的任何代碼。隱藏屬性背後的領域掩蓋了這種關係，並且也可能阻礙表現。

來源

2013-02-02 00:04:07 supercat

返回計算結果和狀態。最佳實踐

回答

相關問題