javadoc 中的策略模式
由于研究原因，我正在搜索 Javadoc 以识别 Javadoc 内“策略模式”的实现。我发现有两个类实际上继承自 FilterInputStream 类：BufferedInputStream 类和 DataInputStream 类。继承的类重写了FilterInputStream类的read()方法。现在根据“策略模式”，我必须从Javadoc中的另一个类中找到一个方法，该方法在其主体中调用read()方法以及。有人可以帮助我吗？
PS 如果您有任何其他 Javadoc 中策略模式的实现，请告诉我。
提前致谢
I am searching Javadoc to identify an implementation of the "strategy pattern" inside Javadoc due to research reasons. I found 2 classes that actually inherited from the FilterInputStream class, the class BufferedInputStream and the DataInputStream. The inherited classes override the read() method of FilterInputStream class. Now according to "strategy pattern" I have to find a method from another class in Javadoc which in its body the read() method is called as well. Can anyone help me, please?.
P.S If you have any other implementation of strategy pattern inside Javadoc in your mind please tell me.
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
输入流看起来更像是装饰器模式而不是策略的示例。
策略模式的更好示例是在
ThreadPoolExecutor。编辑：
RejectedExecutionHandler是一个策略接口，它确定ThreadPoolExecutor如何处理任务的拒绝。此类策略有多种具体实现（ThreadPoolExecutor.AbortPolicy、ThreadPoolExecutor.DiscardPolicy 等）。 ThreadPoolExecutor 可以配置为使用其中之一。因此，它对应于这张图片（来自wikipedia 文章) 的方式如下：
ThreadPoolExecutor是一个ContextRejectedExecutionHandler是一个Strategy接口ThreadPoolExecutor.AbortPolicy，ThreadPoolExecutor.DiscardPolicy是具体策略（ConcreteStrategyA，ConcreteStrategyB）Input streams look more as an example of Decorator pattern rather than Strategy.
Better examples of strategy pattern are uses of
ThreadFactoryandRejectedExecutionHandlerinThreadPoolExecutor.EDIT:
RejectedExecutionHandleris an interface of a strategy which determines howThreadPoolExecutorhandles rejection of tasks. There are several concrete implementations of such strategires (ThreadPoolExecutor.AbortPolicy,ThreadPoolExecutor.DiscardPolicy, etc).ThreadPoolExecutorcan be configured to use one of them.So, it corresponds to this picture (from wikipedia article) in the following way:
ThreadPoolExecutoris aContextRejectedExecutionHandleris aStrategyinterfaceThreadPoolExecutor.AbortPolicy,ThreadPoolExecutor.DiscardPolicyare concrete strategies (ConcreteStrategyA,ConcreteStrategyB)我想说的是任何使用Java的 ServiceLoader 方案正在使用策略模式。基本上，算法（可能是其中的一大套）直到运行时才确定。 Service Loader 本身成为一种主策略（也许这不是这里的主题），但是任何使用
ServiceLoader（例如，CharsetDecoder）的东西都遵循策略模式方法。编辑添加以响应评论：我对“策略模式”的理解是，它是一个父对象，可以在执行时决定并注入一个或多个特定算法。因此，ServiceLoader 本身并不是一种策略模式，但通过 SPI 使用策略模式为 JDK 和其他应用程序的许多领域提供了便利。
但也许我把事情搞得太困难了。基本上，
Collections.sort(List, Comparator)以及任何带有Comparator构造函数参数的已排序集合（例如，新TreeSet(比较器)也是示例。因为，在执行时，可以将任何合适的比较器提交给sort()或构造函数，以便通常在策略中更改行为。模式中，在执行时可以选择多种实现方式——例如，可以按递增/递减日期、主题或发件人地址顺序对电子邮件表进行排序。关联的比较器。I'd say that anything that uses Java's ServiceLoader scheme is using the strategy pattern. Basically the algorithms (maybe a huge suite of them) are undecided until runtime. Service Loader itself becomes a sort of master strategy (maybe that's off topic here) but anything that uses the
ServiceLoader(e.g.,CharsetDecoder) is following the strategy pattern approach.Edit to add in response to comment: My understanding of "strategy pattern" is that it is a parent object into which a specific algorithm or algorithms may be decided upon and injected at execution time. So ServiceLoader itself is not a strategy pattern, but facilitates many areas of the JDK and other applications via SPI that employ the strategy pattern.
But maybe I'm making it too difficult. Basically,
Collections.sort(List, Comparator)and any of the sorted collections withComparatorconstructor arguments (e.g.,new TreeSet(Comparator)are also examples. Why? Because, at execution time, any suitable comparator may be submitted to thesort()or constructor in order to change behavior. Normally in the Strategy pattern, there would be a number of implementations that could be chosen at execution time -- think for example of a table of emails that may be sorted by increasing/decreasing date, subject, or from-address order. Each of these would have an associatedComparator.