接口上用于强制一致性的静态方法的替代方法

jay*_*hao 28 java oop interface

在Java中,我希望能够定义标记接口,强制实现提供静态方法.例如,对于简单的文本序列化/反序列化,我希望能够定义一个看起来像这样的接口:

public interface TextTransformable<T>{

  public static T fromText(String text);

  public String toText();
Run Code Online (Sandbox Code Playgroud)

由于Java中的接口不能包含静态方法(如许多其他帖子/线程中所述:此处,此处,此处此代码不起作用.

然而,我正在寻找的是表达相同意图的一些合理范例,即对称方法,其中一个是静态的,并由编译器强制执行.现在我们能想到的最好的是某种静态工厂对象或通用工厂,这两者都不是真正令人满意的.

注意:在我们的例子中,我们的主要用例是我们有许多很多"值对象"类型 - 枚举或其他具有有限数量值的对象,通常不会超出其值,并且我们解析/ de -parse数秒钟的时间,所以实际上关心重用实例(如Float,Integer等)及其对内存消耗的影响/ gc

有什么想法吗?

编辑1:为了消除一些混乱 - 我们有许多不同的对象适合这种模式 - 实际上我们正试图为具有2个语义的调用者提出一些优雅的东西:

  • 作为合同的接口 - 访问的统一性(例如TextTransformable作为一种能力)
  • 需要通过子类/实现来实现(例如,强制它们实现自己的转换

就我们对Flyweight,Factories的看法而言 - 它们都是我们考虑过的选项,我们真的试图看看我们是否能找到更优雅的东西,而不是依靠JavaDoc说"实现工厂并委托调用它,或按惯例在XXX地点公开"

Yis*_*hai 7

这非常适合Flyweight.这基本上就是你想用静力学来完成的.在如何为Flyweight对象提供服务以便您不创建数千个对象方面,这里有一些想法.

一个是工厂,你说你想到并拒绝,虽然你没有说明原因(所以任何其他想法可能会遇到同样的问题)所以我不会进入它.

另一种方法是使值类型具有可以为其转换器提供服务的方法.像这样的东西:

 public class ValueType {
       public static final TextTransformable<ValueType> CONVERT = ....
 }
Run Code Online (Sandbox Code Playgroud)

然后像这样使用它:

 ValueType value = ValueType.CONVERT.fromText(text);

 String text = ValueType.CONVERT.toText(value);
Run Code Online (Sandbox Code Playgroud)

现在这并没有强制所有ValueType都通过相同的机制提供他们的转换器,为此我认为你需要某种工厂.

编辑:我想我不知道你发现什么工厂不优雅,但我认为你专注于打电话,所以这对你有什么感受:

  ValueType value = getTransformer(ValueType.class).fromText(text);
Run Code Online (Sandbox Code Playgroud)

以上可以通过工厂的静态导入和具有如下签名的方法来完成:

   public static <T> TextTransformable<T> getTransformer(Class<T> type) {
         ...
   }
Run Code Online (Sandbox Code Playgroud)

找到合适的变换器的代码不一定是最漂亮的,但从调用者的角度来看,一切都很好.

编辑2:进一步思考,我看到你想要控制对象构造.你真的不能这样做.换句话说,在Java中,您无法强制实现者使用或不使用工厂来创建其对象.他们总是可以公开一个公共构造函数.我认为你的问题是你对执行建设的机制不满意.如果这种理解是正确的,那么可能会使用以下模式.

您创建一个只包含私有构造函数的对象,它包装您的值类型.该对象可以具有泛型类型参数,以了解它包装的值类型.此对象使用静态工厂方法进行实例化,该方法使用工厂接口创建"实际"值对象.使用该对象的所有框架代码仅将此对象作为参数.它不直接接受值类型,并且如果没有值类型的工厂,则无法实例化该对象.

这种方法的问题在于它是非常有限的.只有一种方法可以创建对象(工厂界面支持的对象),并且使用值对象的能力有限,因为处理这些文本元素的代码仅通过此对象进行了有限的交互.

我猜他们说没有软件问题无法通过额外的间接层解决,但这可能是一个过头的桥梁.至少它值得深思.