比較VS阿帕奇BeanComparator

考慮一個簡單的類：比較VS阿帕奇BeanComparator

class Employee { 

String name; 
int sal; 

....//getters and setters 
}

我可以建立一個比較器進行排序，例如字段名。

class EmpSortByName implements Comparator<Employee>{ 

@Override 
public int compare(Employee e1, Employee e2){ 
    return e1.getName().compareTo(e2.getName()); 
} 
}

然而，看着阿帕奇百科全書BeanComparator，排序可以用以下方式實現的：通過使用BeanComparator

BeanComparator bc = new BeanComparator("name"); 
Collections.sort(employeeList, bc);

因此，我可以做到用最少的代碼排序。在使用比較器和BeanComparators之間有什麼權衡：就性能，使用場景（多領域排序，其他因素）而言？

我也明白要使用BeanComparator，必須導入beanutils jar。

來源

2012-07-11 aces.

這是一個很小的「明顯的」代碼比較多的一個屬性。不要忘記你不知道BeanComparator的功能是什麼，並且可能比第一種方式的性能更差 – 2012-07-11 21:18:26

BeanComparator使用反射來訪問name屬性並比較兩個對象。儘管反射性能有所提高，但仍然不如直接訪問字段的速度快。這是否重要取決於它在應用程序中調用了多少次，以及在哪種情況下調用。

另一個問題是，如果您重構方法並將其重命名爲getLastName()，那麼使用BeanComparator的代碼將不會被重構，直到運行時（或單元測試時間），問題纔會被忽視。

坦率地說，實現一個比較器非常容易，我不認爲使用反射是一個好主意。避免4行代碼的好處不足以彌補它引起的性能和可維護性問題。

來源

2012-07-11 21:24:35

完全贊同+1 – MaVRoSCy 2012-07-11 21:29:41

@JB你是對的，由於反思會有性能問題。 BeanComparator在什麼情況下使用？「最小」代碼是唯一的原因嗎？你能想到其他原因嗎？ – 2012-07-11 21:52:12

我從來沒有必要自己使用它，但我可以想象在單元測試中使用它，或者當UI允許動態選擇哪些屬性對象必須被排序時，或者在像displaytag這樣的必須比較的JSP標記中豆甚至不知道他們的類型，而不需要開發者提供比較器 – 2012-07-11 21:57:50

還與beancomparator您可以輕鬆地與compareTuple org.ujac.util.BeanComparator beanComparator = new org.ujac.util.BeanComparator(compareTuple); Collections.sort(List,beanComparator);

來源

2013-01-17 06:20:01 Janith

比較VS阿帕奇BeanComparator

回答

相關問題