注釋是在Java 5中引入的，我們都為之興奮。 如此出色的工具可以縮短代碼！ 不再有Hibernate / Spring XML配置文件！ 只是注釋，就在我們需要它們的代碼中。 沒有更多的標(biāo)記接口 ，只有運(yùn)行時(shí)保留的 反射可發(fā)現(xiàn)注釋！ 我也很興奮。 此外，我制作了一些開源庫，這些庫大量使用注釋。 以jcabi-aspects為例。 但是，我不再感到興奮。 而且，我相信注釋是Java設(shè)計(jì)中的一個(gè)大錯(cuò)誤。

長(zhǎng)話短說，注釋存在一個(gè)大問題-它們鼓勵(lì)我們?cè)趯?duì)象 外部實(shí)現(xiàn)對(duì)象功能，這與封裝的原理背道而馳 。 該對(duì)象不再是固體，因?yàn)樗男袨椴皇峭耆善渥约旱姆椒ǘx的-它的某些功能保留在其他地方。 為什么不好？ 讓我們看幾個(gè)例子。

@Inject

假設(shè)我們使用@Inject注釋屬性：

import javax.inject.Inject; public class Books {@Injectprivate final DB db;// some methods here, which use this.db }

然后我們有一個(gè)注入器，它知道要注入什么：

Injector injector = Guice.createInjector(new AbstractModule() {@Overridepublic void configure() {this.bind(DB.class).toInstance(new Postgres("jdbc:postgresql:5740/main"));}} );

現(xiàn)在我們正在做的類的實(shí)例Books通過容器：

Books books = injector.getInstance(Books.class);

Books類不知道如何以及誰將類DB實(shí)例注入其中。 這將在幕后和無法控制的地方發(fā)生。 注射即可。 看起來很方便，但是這種態(tài)度會(huì)對(duì)整個(gè)代碼庫造成很大的損害。 控件丟失（不是倒置，而是丟失！）。 該對(duì)象不再負(fù)責(zé)。 它不能對(duì)發(fā)生的事情負(fù)責(zé)。

相反，這是應(yīng)該如何做：

class Books {private final DB db;Books(final DB base) {this.db = base;}// some methods here, which use this.db }

本文說明了為什么首先要使用依賴注入容器是一個(gè)錯(cuò)誤的主意： 依賴注入容器是代碼污染者 。 注釋基本上激發(fā)了我們制造容器并使用它們。 我們將功能移出對(duì)象之外，然后將其放入容器或其他地方。 那是因?yàn)槲覀儾幌胍槐橛忠槐榈刂貜?fù)相同的代碼，對(duì)嗎？ 沒錯(cuò)，復(fù)制是不好的，但是將對(duì)象撕裂甚至更糟。 更糟 對(duì)于ORM（JPA / Hibernate），也正是如此，在其中正在積極使用注釋。 檢查這篇文章，它解釋了ORM的問題： ORM是一種進(jìn)攻性的反模式 。 注釋本身并不是主要?jiǎng)訖C(jī)，但它們通過將對(duì)象撕裂并在不同位置保留零件來幫助我們和鼓勵(lì)我們。 它們是容器，會(huì)話，管理器，控制器等。

@XmlElement

要將POJO轉(zhuǎn)換為XML時(shí)，這就是JAXB的工作方式 。 首先，將@XmlElement批注附加到getter：

import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlRootElement; @XmlRootElement public class Book {private final String title;public Book(final String title) {this.title = title;}@XmlElementpublic String getTitle() {return this.title;} }

然后，創(chuàng)建一個(gè)編組器，并要求它將Book類的實(shí)例轉(zhuǎn)換為XML：

final Book book = new Book("0132350882", "Clean Code"); final JAXBContext ctx = JAXBContext.newInstance(Book.class); final Marshaller marshaller = ctx.createMarshaller(); marshaller.marshal(book, System.out);

誰在創(chuàng)建XML？ 不是book 。 課堂以外的其他人Book 。 這是非常錯(cuò)誤的。 相反，這是應(yīng)該完成的方式。 首先，不了解XML的類：

class DefaultBook implements Book {private final String title;DefaultBook(final String title) {this.title = title;}@Overridepublic String getTitle() {return this.title;} }

然后，將其打印到XML的裝飾器 ：

class XmlBook implements Book{private final Book origin;XmlBook(final Book book) {this.origin = book;}@Overridepublic String getTitle() {return this.origin.getTitle();}public String toXML() {return String.format("<book><title>%s</title></book>",this.getTitle());} }

現(xiàn)在，為了以XML 印刷書籍，我們執(zhí)行以下操作：

String xml = new XmlBook(new DefaultBook("Elegant Objects") ).toXML();

XML打印功能位于XmlBook 。 如果您不喜歡裝飾器的想法，可以將toXML()方法移至DefaultBook類。 這并不重要。 重要的是，功能始終位于對(duì)象內(nèi)部，即位于對(duì)象所屬的位置。 只有對(duì)象知道如何將自己打印到XML。 沒有人！

@RetryOnFailure

這是一個(gè)示例（來自我自己的庫 ）：

import com.jcabi.aspects.RetryOnFailure; class Foo {@RetryOnFailurepublic String load(URL url) {return url.openConnection().getContent();} }

編譯后，我們運(yùn)行一個(gè)所謂的AOP編織器 ，該編織器從技術(shù)上將我們的代碼轉(zhuǎn)換為如下形式：

class Foo {public String load(URL url) {while (true) {try {return _Foo.load(url);} catch (Exception ex) {// ignore it}}}class _Foo {public String load(URL url) {return url.openConnection().getContent();}} }

我簡(jiǎn)化了在失敗時(shí)重試方法調(diào)用的實(shí)際算法，但是我確定您能理解。 AOP引擎AspectJ使用@RetryOnFailure批注作為信號(hào)，通知我們必須將該類包裝到另一個(gè)類中。 這是在幕后發(fā)生的。 我們沒有看到實(shí)現(xiàn)重試算法的補(bǔ)充類。 但是AspectJ編織器產(chǎn)生的字節(jié)碼包含F(xiàn)oo類的修改版本。

這正是這種方法的問題所在-我們看不到也不控制該補(bǔ)充對(duì)象的實(shí)例化。 對(duì)象組合是對(duì)象設(shè)計(jì)中最重要的過程，它隱藏在幕后的某個(gè)地方。 您可能會(huì)說，因?yàn)樗茄a(bǔ)充，所以我們不需要看它。 我不同意。 我們必須看到我們的對(duì)象是如何構(gòu)成的。 我們可能不在乎它們?nèi)绾喂ぷ?#xff0c;但是我們必須看到整個(gè)合成過程。

更好的設(shè)計(jì)如下所示（而不是注釋）：

Foo foo = new FooThatRetries(new Foo());

然后，執(zhí)行FooThatRetries ：

class FooThatRetries implements Foo {private final Foo origin;FooThatRetries(Foo foo) {this.origin = foo;}public String load(URL url) {return new Retry().eval(new Retry.Algorithm<String>() {@Overridepublic String eval() {return FooThatRetries.this.load(url);}});} }

現(xiàn)在，執(zhí)行Retry ：

class Retry {public <T> T eval(Retry.Algorithm<T> algo) {while (true) {try {return algo.eval();} catch (Exception ex) {// ignore it}}}interface Algorithm<T> {T eval();} }

代碼更長(zhǎng)嗎？ 是。 比較干凈嗎？ 多很多。 我感到遺憾的是，兩年前我開始使用jcabi-aspects時(shí)還不了解它。

底線是注釋不好。 不要使用它們。 應(yīng)該用什么代替呢？ 對(duì)象組成 。

有什么會(huì)比注釋更糟？ 配置 。 例如，XML配置。 Spring XML配置機(jī)制是糟糕設(shè)計(jì)的完美示例。 我已經(jīng)說過很多次了。 讓我再重復(fù)一遍-Spring Framework是Java世界中最差的軟件產(chǎn)品之一。 如果您可以遠(yuǎn)離它，那么您將對(duì)自己有很大幫助。

OOP中不應(yīng)有任何“配置”。 如果它們是真實(shí)對(duì)象，我們將無法對(duì)其進(jìn)行配置。 我們只能實(shí)例化它們。 實(shí)例化的最佳方法是運(yùn)算符new 。 該運(yùn)算符是OOP開發(fā)人員的關(guān)鍵工具。 把它從我們手中奪走并給予我們“配置機(jī)制”是不可原諒的罪行 。

• Java注釋是一個(gè)大錯(cuò)誤（在線講座＃14）； 2016年5月4日; 744意見; 13個(gè)贊
• 依賴注入容器不是一個(gè)好主意（網(wǎng)絡(luò)研討會(huì)9）； 2015年12月1日； 1264意見; 19個(gè)贊
• 為何吸氣與反吸是反模式？ （第4場(chǎng)網(wǎng)絡(luò)研討會(huì)）； 2015年7月1日； 3095次點(diǎn)擊; 53個(gè)贊

翻譯自: https://www.javacodegeeks.com/2016/11/java-annotations-big-mistake.html

總結(jié)

以上是生活随笔為你收集整理的Java注释是一个大错误的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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