您是否曾經(jīng)進行過代碼審查，記錄了非常高的WTF / m？ 您是否想知道所有這些錯誤代碼的原因是什么？ 在大多數(shù)情況下，導(dǎo)致原因1的主要原因是使用設(shè)計和編碼反模式。

如果您喜歡定義，請參見以下內(nèi)容：AntiPattern是一種文學形式，它描述了對問題的普遍存在的解決方案，該解決方案產(chǎn)生肯定的負面影響。 AntiPattern可能是由于經(jīng)理或開發(fā)人員不了解更好，沒有足夠的知識或經(jīng)驗來解決特定類型的問題或在錯誤的情況下應(yīng)用了完美的模式而導(dǎo)致的。

重新發(fā)明輪子

IMO經(jīng)常發(fā)生的反模式是缺乏對某些有用框架/庫的了解。 Apache commons lang和commons集合是每個Java項目中都應(yīng)該存在的依賴項。

您可以編寫自己喜歡的循環(huán)過濾或選擇集合中的某些對象的方法，也可以使用CollectionUtils.select（…）或CollectionUtils.filter（…）。

您可以執(zhí)行一些花哨的非null檢查，最后以巨大的if-else構(gòu)造結(jié)束，或者可以使用StringUtils.isNotBlank（…）。 由你決定。

一般規(guī)則是不要試圖重新發(fā)明輪子。 有些人喜歡編寫自己的Reflection utils，而Apache的commons beanutils ，Spring的BeanUtils和BeanWrapper可以解決問題。

貨物崇拜編程

貨物崇拜編程是一種編程樣式，其中使用模式和方法而不了解原因。 “貨運邪教”一詞最初是指第二次世界大戰(zhàn)后在南太平洋長大的土著宗教。 這些團體的做法集中在建造精美的飛機和軍事起落跑道的模型上，以期召喚在戰(zhàn)爭中帶來奇妙貨物的神似飛機。

大多數(shù)情況下，熟練的或經(jīng)驗不足的程序員都會使用這種編程方式，從其他地方復(fù)制粘貼某些代碼。
例子：
–在自說明代碼中添加不必要的注釋 –為沒有問題的垃圾將自動收集的對象添加刪除代碼 –創(chuàng)建工廠以構(gòu)建簡單的對象

通過例外/期望處理進行編碼

代替 檢查某些特定的轉(zhuǎn)折情況值（例如null值）的方法，有些人喜歡捕獲NullPointerException并在catch塊中執(zhí)行一些邏輯。 這種編碼方式稱為期望處理，因為預(yù)期會發(fā)生異常。

發(fā)明了異常是為了通知您以下事實：確實發(fā)生了一些非常糟糕的事情，但并不意味著經(jīng)常將它們拋出。 這就是為什么它們被稱為“例外”。 如果發(fā)生這種情況，請仔細處理它們，但不要濫用它們以執(zhí)行某些本可以通過簡單的if-else檢查實現(xiàn)的邏輯。

避免/吞咽異常

參考前面的反模式，當引發(fā)異常時，意味著發(fā)生了意外情況。 您應(yīng)該做的最后一件事是吞下這些異常，而不是處理其有用的信息。

例如，如果您有一個只希望返回一個對象的方法，因為它希望它是唯一的，則對返回結(jié)果列表的數(shù)據(jù)庫查詢進行性能檢查，檢查該列表的大小是否等于1，然后執(zhí)行只能返回1個唯一對象的查詢。結(jié)果（如果沒有拋出異常）。 如果要實現(xiàn)類似的東西，則意味著預(yù)期的對象可能不是唯一的，這意味著實現(xiàn)與分析中所說的有所不同。

繼承地獄

繼承應(yīng)謹慎處理。 它非常有用，但是您只能使用它的預(yù)期用途。 如果繼承樹變得腫，那是不對的。 不要為1種特定情況編寫抽象類。 請改用合成。 策略模式可以在這里派上用場。

例如，如果您的JSF托管bean'EditUserManagedBean'擴展了AbstractEditingManagedBean，又擴展了AbstractSelectionManagedBean，又擴展了AsbtractParentDetailManagedBean，又擴展了AbstractManagedBean，則您應(yīng)該知道有些錯誤，并且應(yīng)該有其他方法可以實現(xiàn)此行為

鍍金 和過早優(yōu)化

有些人喜歡通過繼續(xù)努力來改進代碼，直到付出額外的努力才增加了價值，而不是堅持要求。 此處犯的錯誤是，使最終用戶看到產(chǎn)品中的其他或增強功能比用戶要求或期望的功能更加高興。 用戶可能對結(jié)果感到失望，而開發(fā)人員的額外努力可能是徒勞的。 該過程稱為鍍金。

鍍金與過早的優(yōu)化有關(guān)。 過早的優(yōu)化是指考慮將來可能會出現(xiàn)的問題，但目前還不是這種情況。 您應(yīng)該只考慮所要求的內(nèi)容和要求的內(nèi)容，而不要考慮最終可能對將來的目的有用的內(nèi)容。 頻繁發(fā)生的過早優(yōu)化是過早的性能優(yōu)化。 如果此時不存在性能問題，請不要嘗試處理它們，當它們發(fā)生時再進行處理。

參考文獻

• 由我們的JCG合作伙伴 Glenn Dejaeger在about：software development中 編程反模式 。
• http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns

相關(guān)文章 ：

• JDK中的設(shè)計模式
• 正確記錄應(yīng)用程序的10個技巧
• 每個程序員都應(yīng)該知道的事情
• Java教程和Android教程列表

翻譯自: https://www.javacodegeeks.com/2011/10/programming-antipatterns.html

總結(jié)

以上是生活随笔為你收集整理的编程反模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。