我的DRY和KISS原則迷戀的追隨者,但上週我曾在那裏似乎都相互矛盾的情形:當KISS和DRY碰撞
對於一個應用程序,我在幹什麼,我不得不實施對於次的循環,其執行以下操作:
- 迭代過A型
- 的列表的元素轉換類型A的元件到類型B,並將它們插入到類型B的列表
下面是一個例子:
for (A a : listOfA) {
listOfB.add(BFactory.convertFromAToB(a));
}
中的代碼,我必須這樣做,約4倍,轉換類型(例如, D,E等)到另一個。我可能無法更改要轉換的類型,因爲它們是我們必須在應用程序中使用的第三方類型。
因此,我們有:
for (A a : listOfA) {
listOfB.add(BFactory.convertFromAToB(a));
}
for (C a : listOfC) {
listOfB.add(DFactory.convertFromCToD(c));
}
...
所以,爲了不違反乾的,我想出了一個通用的解決方案:
private interface Function<S, T> {
T apply(S s);
}
public <S, T> void convertAndCopy(List<S> src, List<T> dst, Function<S, T> f) {
for (S s : src) {
dst.add(f.apply(s));
}
}
調用看起來是這樣的:
convertAndCopy(listOfA, listOfB, new Function<A, B>() {
A apply(B b) {
return CFactory.convertFromBToC(b);
}
});
現在,雖然這在DRY方面更好,但我認爲它違反了KISS,因爲此解決方案難以滿足而不是重複的for循環。
那麼,這是幹還是吻?在這種情況下,哪一個贊成?
編輯
只是要清楚,我說的這個類是適配器,其代表稱遺留系統,以我們自己的實現,傳統轉換成我們自己的類型沿途。我無法更改遺留類型,也不能更改我們的類型(這是XML-Schema生成的)。
關鍵字:JAVA幹吻 - 愛它! – hawkeye
「幹」是什麼意思?啊,答案說,不要重複自己,我猜。 –
@天使,我會在稍後添加引用:-)。 – helpermethod