威海北京网站建设,百度广告怎么推广,企业网站建设网站模板,成都网站建设的定位API的发展绝对是不平凡的。 只有少数几个需要处理的事情。 我们大多数人每天都在使用内部专有API。 现代IDE附带了很棒的工具#xff0c;可以分解#xff0c;重命名#xff0c;上拉#xff0c;下推#xff0c;间接#xff0c;委托#xff0c;推断#xff0c;泛化我们的… API的发展绝对是不平凡的。 只有少数几个需要处理的事情。 我们大多数人每天都在使用内部专有API。 现代IDE附带了很棒的工具可以分解重命名上拉下推间接委托推断泛化我们的代码伪像。 这些工具使重构我们的内部API变得轻而易举。 但是我们中的一些人在公共API上工作规则在此方面发生了巨大变化。 如果正确完成则对公共API进行版本控制。 每次更改兼容或不兼容都应在新的API版本中发布。 多数人会同意API升级应在主要版本和次要版本中完成类似于语义版本控制中指定的内容 。 简而言之不兼容的API更改发布在主要版本1.0、2.0、3.0中而兼容的API更改/增强发布在次要版本1.0、1.1、1.2中。 如果您正在计划那么您将在很长时间内预见到大多数不兼容的更改然后才实际发布下一个主要版本。 Java中一个早日宣布这种变化的好工具是弃用 。 接口API的演变 现在弃用是一个很好的工具它表明您将要从API中删除类型或成员。 如果要在接口的类型层次结构中添加方法或类型怎么办 这意味着实现您的接口的所有客户端代码都将中断–至少只要尚未引入Java 8的防御方法即可。 有几种技术可以规避/解决此问题 1.不在乎 是的这也是一种选择。 您的API是公开的但使用的程度可能不是很高。 让我们面对现实并不是我们所有人都在JDK / Eclipse / Apache / etc等代码库上工作。 如果您很友好则至少要等待主要版本引入新方法。 但是如果确实需要您可以打破语义版本控制的规则-如果您可以处理引起一群愤怒的用户的后果。 但是请注意其他平台并不像Java Universe那样向后兼容通常是根据语言设计或语言复杂性。 例如使用Scala将事物声明为隐式的各种方法您的API并不总是完美的。 2.用Java方式完成 “ Java”方式根本不发展接口。 JDK中的大多数API类型一直以来都是今天。 当然这使API感觉很“恐龙化”并在各种相似类型之间例如StringBuffer和StringBuilder或Hashtable和HashMap增加了很多冗余。 请注意Java的某些部分不遵循“ Java”方式。 最具体地说JDBC API就是这种情况它根据第1节“不关心它”的规则演变。 3.用Eclipse的方式来做 Eclipse的内部包含大量API。 在Eclipse中进行开发时 有很多指导方针如何开发自己的API即插件的公共部分。 关于Eclipse人员如何扩展接口的一个示例是IAnnotationHover类型。 根据Javadoc合同它允许实现也实现IAnnotationHoverExtension和IAnnotationHoverExtension2 。 显然从长远来看这种经过改进的API很难维护测试和记录文档最终很难使用 考虑ICompletionProposal及其6扩展类型 4.等待Java 8 在Java 8中您将能够使用防御者方法 。 这意味着您可以为新的接口方法提供明智的默认实现 如Java 1.8的java.util.Iterator 摘录所示 public interface IteratorE {// These methods are kept the same:boolean hasNext();E next();// This method is now made optional (finally!)public default void remove() {throw new UnsupportedOperationException(remove);}// This method has been added compatibly in Java 1.8default void forEach(Consumer? super E consumer) {Objects.requireNonNull(consumer);while (hasNext())consumer.accept(next());}
} 当然您并不总是希望提供默认的实现。 通常您的界面是必须完全由客户端代码实现的合同。 5.提供公共默认实现 在许多情况下明智的做法是告诉客户端代码他们可能需要自己承担实现接口的风险由于API的发展因此他们应该更好地扩展提供的抽象或默认实现。 一个很好的例子是java.util.List 可能很难正确实现。 对于简单的对性能不重要的自定义列表大多数用户可能选择扩展java.util.AbstractList 。 然后剩下剩下要实现的唯一方法是getint和size。所有其他方法的行为都可以从这两个方法中得出 class EmptyListE extends AbstractListE {Overridepublic E get(int index) {throw new IndexOutOfBoundsException(No elements here);}Overridepublic int size() {return 0;}
} 遵循的一个很好的约定是如果您的默认实现为AbstractXXX则将其命名为默认实现如果是具体的则将其命名为DefaultXXX 6.使您的API很难实现 现在这并不是真正的好技术而只是一个可能的事实。 如果您的API很难实现一个接口中有100多个方法则用户可能不会这样做。 注意 可能 。 永远不要低估疯狂的用户。 一个示例是jOOQ的 org.jooq.Field类型它表示数据库字段/列。 实际上这种类型是jOOQ 内部域特定语言的一部分 提供了可以在数据库列上执行的各种操作和功能。 当然拥有太多方法是一个例外并且-如果您不设计DSL-可能表明整体设计不佳。 7.添加编译器和IDE技巧 最后但并非最不重要的一点是您可以将一些巧妙的技巧应用于您的API以帮助人们了解他们应该做些什么以便正确实现基于接口的API。 这是一个艰难的例子将API设计人员的意图直接扑向您的脸。 考虑一下org.hamcrest.Matcher API的摘录 public interface MatcherT extends SelfDescribing {// This is what a Matcher really does.boolean matches(Object item);void describeMismatch(Object item, Description mismatchDescription);// Now check out this method here:/*** This method simply acts a friendly reminder not to implement * Matcher directly and instead extend BaseMatcher. Its easy to * ignore JavaDoc, but a bit harder to ignore compile errors .** see Matcher for reasons why.* see BaseMatcher* deprecated to make*/Deprecatedvoid _dont_implement_Matcher___instead_extend_BaseMatcher_();
} “友好的提醒” 来吧。 其他方法 我敢肯定还有许多其他方法可以开发基于接口的API。 我很好奇您的想法 参考 JAVASQL和ANDOQ博客上的JCG合作伙伴 Lukas Eder 提供了Java接口的防御性API演变 。 翻译自: https://www.javacodegeeks.com/2013/02/defensive-api-evolution-with-java-interfaces.html
