代碼越少越好？ 對象越少越好？ 是真的嗎 像往常一樣，這取決于。

在某些情況下，通過添加更多內容，我們會添加不必要的復雜性。 當我們僅出于“將來可能需要這種額外的靈活性”而創建接口或其他抽象時，就會發生這種情況。 當我們忘記YAGNI原理而我們編寫的代碼可能會使我們的生活變得更輕松，如果出現了新的需求，這些需求可能永遠不會發生。

另一方面，我們遇到的情況與我在最近的文章中描述的情況類似。 我向您展示了一個示例，其中我們添加了一些內部執行幾乎相同的方法。 但是，通過添加它們，我們獲得了很多好處–代碼變得更易于理解。 此附加代碼為我們提供了有關對象正在執行的操作的信息，而不是如何實現的。

今天，我想與大家分享另一個例子，該例子表明更少的代碼有時可能意味著更少的可讀性代碼。

很久以前…

今天，我想和您談談歷史：

public class History {public void store( Author author, RefactoringType type, Scope scope, RefactoringJustification justification, Date today) {// some code }

是否容易弄清楚要存儲哪種存儲方法？ 有可能理解嗎？ 好吧，即使是這樣，我相信我們所有人都可以同意這絕對是困難的。

您如何從方法的聲明中提取必要的信息？ 我可以假設，首先您要閱讀類和方法的名稱以查找上下文。 好，我們有。 我們想存儲一些歷史信息。 現在最困難的部分開始了–您必須找出我們要存儲的內容。 您不能只是簡單地閱讀此信息，因為該信息不存在于代碼中。 在這種情況下，您可能會嘗試通過查看參數列表來查找此信息。 您將閱讀它們，并希望能夠弄清楚代碼的作者想要存儲什么。

或者，您可以查看引入此代碼的提交消息。

或者，您可以查看方法的定義并在實現中尋找答案。

雖然不是最好的主意。

您是否認為輕松獲得此信息會很棒？ 要擁有無需額外努力就能理解的代碼？ 我相信這正是我們應該如何編寫的方式。

救援參數對象

為什么在閱讀完方法的聲明后還不了解所有內容？

通過某種方式，我們可以在這里找到有關歷史的信息–班級名稱為我們提供了這些信息。

我們知道這與存儲內容有關–該方法的名稱具有很強的描述性。

問題在于我們不知道要在歷史記錄中存儲什么。 為什么？ 因為輸入參數沒有給我們這些信息。

這些參數指示我們要存儲的塊，但是，不解釋當將所有這些塊放在一起時我們應該知道什么。 我們正在獲取有關實現（使用的部分）的信息，我們不知道此代碼應該做什么。

我們能做什么？ 我們應該隱藏實現并解釋我們希望通過此代碼實現的目標。 那就是那一刻
參數對象可以解決。 您可以將其視為一些不同對象的盒子，作為可以減少依賴性的解決方案。 但是，對我而言，使用此模式的最大好處是您將不得不命名該對象，并因此而不得不提供有價值的信息。

讓我給你演示：

public class History {public void store(CodeDelta delta) {// some code }

現在很明顯我們要存儲什么。 我們與閱讀我們代碼的人共享有用的信息。 我們還隱藏了一個實現。 他們可以專注于重要的事情，而不會被僅在編寫或修改方法時才感興趣的所有其他細節所打擾。

那么，您說的越少越好？

翻譯自: https://www.javacodegeeks.com/2016/07/many-parameters-lost-information.html

總結

以上是生活随笔為你收集整理的许多参数和丢失的信息的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。