非静态创建新方法?
我有时编写可以转换为其他内容或从其他内容转换的类,并且我习惯将其编写为非静态转换方法和静态转换方法,例如:
class A {
B toB() {...}
static A fromB(B b) {...}
}
或者
class B {
void save(File f) {...}
static B load(File f) {...}
}
我曾经认为它是一个很好且简单的方法,但最近转换源方法的静态性一直困扰着我,例如,如果我想为可以转换为和从 - B
:
interface ConvertableToAndFromB {
B toB();
// ?
}
那么,有没有一种优雅的方法可以做到这一点,而无需转换为静态,而不是迁移到 Smalltalk?
编辑
为了澄清,我意识到我可以在接口中添加一个非静态方法,例如:
interface ConvertableToAndFromB {
B toB();
void fromB(B b);
}
或者,如果我想允许不可变类型(感谢Stripling):
interface ConvertableToAndFromB<T implements ConvertibleToAndFromB<T>> {
B toB();
T fromB(B b);
}
但这需要我创建一个新的A
在我什至可以调用它之前,如:
A a = new A();
a.fromB(b);
或(对于不可变):
A a = new A();
a = a.fromB(b);
这是我试图避免的(但没有其他解决方案)。我只是希望有更好的方法。
I sometimes write classes which can be converted to- and from- something else, and I'm used to writing it as a non-static convert-to method and a static convert-from method, for example:
class A {
B toB() {...}
static A fromB(B b) {...}
}
or
class B {
void save(File f) {...}
static B load(File f) {...}
}
I used to think it's a good and simple approach, but lately the static-ness of the conversion-from method has been annoying me, for instance if I want to define an interface for types that can be converted to- and from- B
:
interface ConvertableToAndFromB {
B toB();
// ?
}
So, is there an elegant way of doing that without having the conversion-from as static, other than migrating to Smalltalk?
EDIT
To clarify, I realize I can add a non-static method in the interface, e.g.:
interface ConvertableToAndFromB {
B toB();
void fromB(B b);
}
or, if I want to allow immutable types (thanks Stripling):
interface ConvertableToAndFromB<T implements ConvertibleToAndFromB<T>> {
B toB();
T fromB(B b);
}
But that will require me to create a new A
before I can even invoke this, as in:
A a = new A();
a.fromB(b);
or (for immutable):
A a = new A();
a = a.fromB(b);
which is what I'm trying to avoid (but will do with no other solution). I just hope there's a nicer way.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您应该能够使您的界面递归通用。我相信语法是这样的:
像这样使事情变得更强类型有明显的优势。但是,这确实意味着您在调用
fromB
时必须稍微了解所需的实际类型。这种方法有优点也有缺点。附带说明一下,让
A
负责生成A
或B
类型的对象违反了单一职责原则,我通常更喜欢有一个单独的 Converter 类或接口来执行这些操作。You should be able to make your interface recursively generic. I believe the syntax is like this:
Making things more strongly typed like this has obvious advantages. However, it does mean that you have to be somewhat aware of the actual type that you want when you call
fromB
. There are advantages and disadvantages to this approach.As a side note, making
A
responsible for generating objects of typeA
orB
violates the Single Responsibility Principle, and I would generally prefer to have a separate Converter class or interface to perform these actions.通常,fromB 方法将被实现为复制构造函数。例如,
不幸的是,这不能帮助您创建一个接口来抽象所述功能。通常,可以使用单独的工厂,并且该工厂实现一个接口,但这仍然不允许您以非静态方式在对象中实现该方法,同时避免不必要的实例化。
Often, a fromB method would be implemented as a copy constructor. E.g.
Unfortunately this does not help you create an interface to abstract said functionality. Normally, a separate factory could be used, and this factory implement an interface, but this would still not allow you to get around being able to implement the method in your object in a non-static way while avoiding unnecessary instantiation.
在你的场景中,我会这样做:
In your scenario, I'll do it this way:
创建实用程序帮助器类可能会更好,因为如果您考虑一下,对话与对象/实例无关。
例如,当您将数组转换为列表时,您不会执行 arr.asList() ,而是使用 Arrays.asList(arr)
creating a utility helper class might be better because if you think about it, conversation has nothing to do with the object/instance.
for example, when you convert an array to list, you don't do arr.asList(), rather, you use Arrays.asList(arr)