個人而言,我覺得這取決於你的「等價」的定義。根據你的定義,這意味着「當應用程序產生它們的事件時發生同樣的事情」。 但是「同樣的事情」,這是指用戶的觀點還是程序員的觀點?
如果它是前者,那麼問題是多餘的,因爲用戶只需要檢查不同的動作是否導致相同的視覺結果以確定它們是否相等。但是,這需要進一步考慮 - 對於兩個小部件而言,直接的視覺效果可能是相同的,但從長遠來看,這些操作可能對用戶而言不是「等同的」。例如你按下按鈕A,你觀察到A;但是如果你做了一個列表選擇B,你再次觀察到A,但是也可能發生一些用戶沒有檢測到的不可察覺的事件B.從長遠來看,這可能會影響事情。因此,從用戶角度來看,等同可能是一個棘手的問題。
後一種情況很難分析。正如你所提到的,一種方法可能是共享相同的監聽器,即使用相同的方法來處理這兩個小部件。他們可以選擇使用不同的聽衆,甚至可能使用不同的方法,但是如果兩種方法基本上遵循類似的邏輯或目的,他們可能是「等同的」。但是,這可能是特定案例,可能是一個相當細微的話題(比較方法)。
另一個想法:你也可以選擇通過各種不同的測試和widget上的輸入來運行實驗,並派生出一些統計值來爲你的比較指定一個確定性度量(例如,這些小部件相當於超過80%的提供輸入)。當比較文本輸入時,這可能適用於例如JTextArea和JTextField。
你的假設也可能影響你的等價定義。例如假設這些輸入,A和B是等價的。
這些只是我的一些想法和意見。畢竟,它是一份研究論文。希望我提供了一些想法。
編輯
我認爲,事件本身的檢測是一個微不足道的細節。它如何處理這件事很重要。基本上你的問題歸結爲:是否有某種方式比較特定事件的事件處理程序。老實說,我不知道如何做到這一點(比較堆棧,檢查代碼冗餘,檢查是否是關係)。我真的不知道如何做這樣的比較。
對我來說聽起來很合適。 – 2011-04-10 16:25:28
如果應用程序中發生的情況完全相同,但使用了不同的代碼,則這可能是編程不佳的一個症狀。如果使用相同的代碼,這是微不足道的。你是否想找到糟糕的編程例子?你究竟想達到什麼目的? – 2011-04-10 16:46:14