方法鏈接是對象方法返回對象本身以使結果被另一個方法調用的實踐。像這樣：participant.addSchedule(events[1]).addSchedule(events[2]).setStatus('attending').save()這似乎被認為是一種好習慣，因為它會產生可讀的代碼或“流暢的界面”。但是，對我而言，它似乎打破了面向對象本身所隱含的對象調用表示法-生成的代碼不代表對先前方法的結果執(zhí)行的動作，通常這是面向對象的代碼的工作方式：participant.getSchedule('monday').saveTo('monnday.file')這種差異設法為“調用結果對象”的點標記創(chuàng)建了兩種不同的含義：在鏈接的上下文中，以上示例將被視為保存參與者對象，即使該示例實際上旨在保存計劃表也是如此。 getSchedule接收的對象。我知道這里的區(qū)別在于是否應期望被調用方法返回某些內容（在這種情況下，它將返回被調用對象本身進行鏈接）。但是，這兩種情況與符號本身并沒有區(qū)別，僅與被調用方法的語義相區(qū)分。當不使用方法鏈接時，我總能知道方法調用是在與上次調用的結果相關的操作上進行的-通過鏈接，這種假設會中斷，我必須在語義上處理整個鏈，以了解實際對象是什么叫真的是。例如：participant.attend(event).setNotifications('silent').getSocialStream('twitter').postStatus('Joining '+event.name).follow(event.getSocialId('twitter'))在這里，最后兩個方法調用引用getSocialStream的結果，而之前的方法引用參與者。實際在上下文發(fā)生變化的地方寫鏈可能不是一個好習慣（是嗎？），但是即使如此，您也必須不斷檢查看起來相似的點鏈實際上是否在同一個上下文中，或者只在結果上起作用。在我看來，雖然表面上的方法鏈接確實會產生可讀的代碼，但是點符號含義的重載只會導致更多的混亂。由于我不認為自己是編程專家，所以我認為這是我的錯。所以：我想念什么？我是否理解方法鏈接有些錯誤？在某些情況下方法鏈接特別好還是在某些情況下特別糟糕？旁注：我知道這個問題可以理解為掩蓋為問題的意見陳述。但是，它不是-我真正地想理解為什么鏈接被認為是一種好習慣，而在認為鏈接破壞了固有的面向對象表示法的地方我犯了錯。
3 回答
斯蒂芬大帝
TA貢獻1827條經驗 獲得超8個贊
我同意這是主觀的。在大多數情況下，我避免使用方法鏈，但是最近我還發(fā)現了一種情況，那就是正確的做法-我有一個方法可以接受10個參數之類的參數，并且需要更多的參數，但是在大多數情況下，您只需要指定一個很少。使用覆蓋時，這變得非常麻煩。相反，我選擇了鏈接方法：
MyObject.Start()
.SpecifySomeParameter(asdasd)
.SpecifySomeOtherParameter(asdasd)
.Execute();
這有點像工廠模式。方法鏈接方法是可選的，但是它使編寫代碼更容易（尤其是使用IntelliSense）。請注意，這只是一個孤立的案例，并不是我的代碼中的常規(guī)做法。
關鍵是-在99％的情況下，無需方法鏈接就可以做得甚至更好。但這是1％的最佳方法。
犯罪嫌疑人X
TA貢獻2080條經驗 獲得超4個贊
只是我的2美分；
方法鏈接使調試變得棘手：-您不能將斷點放在簡明的位置，因此您可以將程序恰好停在所需的位置-如果這些方法之一引發(fā)異常，并且您獲得了行號，則不知道“鏈”中的哪種方法引起了問題。
我認為通常最好寫短而簡潔的行。每行應該只進行一個方法調用。優(yōu)先選擇更多行而不是更長行。
編輯：評論提到方法鏈接和換行符是分開的。那是真實的。但是，取決于調試器，可能在斷點中間放置斷點，也可能不斷點。即使可以，使用帶有中間變量的單獨的行也可以為您提供更大的靈活性，并提供大量值，您可以在“監(jiān)視”窗口中檢查這些值，以幫助調試過程。
阿晨1998
TA貢獻2037條經驗 獲得超6個贊
就個人而言，我更喜歡只對原始對象起作用的鏈接方法，例如設置多個屬性或調用實用程序類型的方法。
foo.setHeight(100).setWidth(50).setColor('#ffffff');
foo.moveTo(100,100).highlight();
當我的示例中一個或多個鏈接方法將返回foo以外的任何對象時，我不使用它。從語法上講，只要您為鏈中的那個對象使用正確的API，就可以鏈接任何東西，但是更改對象IMHO會使事情變得不那么易讀，并且如果不同對象的API有任何相似之處，則可能會造成混亂。如果你做一些非常常見的方法調用末（.toString()，.print()，等等），其對象是你最終作用在？隨便閱讀代碼的人可能不會發(fā)現它是鏈中隱式返回的對象，而不是原始引用。
鏈接不同的對象也可能導致意外的空錯誤。在我的示例中，假設foo有效，則所有方法調用都是“安全的”（例如，對foo有效）。在OP的示例中：
participant.getSchedule('monday').saveTo('monnday.file')
...無法保證（作為外部開發(fā)人員查看代碼）getSchedule實際上會返回有效的非null調度對象。同樣，調試這種類型的代碼通常要困難得多，因為許多IDE不會在調試時將方法調用評估為可以檢查的對象。IMO，任何時候您可能需要檢查對象以進行調試時，我都希望將其放在顯式變量中。
添加回答
舉報
0/150
提交
取消