The non-static method create-new-from?

Sometimes I write classes that can be converted to and from another, and I'm used to writing it as a non-static conversion method and a static conversion 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 that this is a good and simple approach, but recently the static method of the conversion from me is annoying, for example, 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 to do this without conversion - due to statics other than migration to Smalltalk?

EDIT

To clarify, I understand that I can add a non-static method to the interface, for example:

 interface ConvertableToAndFromB { B toB(); void fromB(B b); } 

or, if I want to allow immutable types (thanks to Stripling):

 interface ConvertableToAndFromB<T implements ConvertibleToAndFromB<T>> { B toB(); T fromB(B b); } 

But this will require me to create a new A before I can even call it, as in:

 A a = new A(); a.fromB(b); 

or (for immutable):

 A a = new A(); a = a.fromB(b); 

what I'm trying to avoid (but I will not do with another solution). I just hope it gets better.

+4
source share
4 answers

Often, the fromB method will be implemented as a copy constructor. For instance.

 public class A { public A(B b) { this.someValue = b.someOtherVariable; } } 

Unfortunately, this does not help you create an interface for an abstract function. You can usually use a separate factory, and this factory implements the interface, but it still will not allow you to do so that it can implement the method in your object non-statically, avoiding unnecessary instantiation.

+1
source

You should be able to make your interface recursively generic. I believe the syntax is as follows:

 interface ConvertibleToAndFromB<T implements ConvertibleToAndFromB<T>>{ B toB(); T fromB(B b); } class A implements ConvertibleToAndFromB<A> { B toB() {...} A fromB(B b); } 

Stronger types of things like this have obvious advantages. However, this means that you need to be aware of the actual type that you want when you call fromB . There are advantages and disadvantages to this approach.

As a side note, creating A , responsible for creating objects of type A or B , violates the principle of shared responsibility, and I usually prefer to have a separate class or converter interface to do this.

 Converter<A, B> converter = converterFactory.get<A, B>(A.class, B.class); B b = converter.from(a); 
+3
source

In your scenario, I will do it as follows:

 interface ConvertableToA { A toA() {...} } interface ConvertableFromA { Object fromA(A a) {...} } class MyConvertableClass implements ConvertableToA, ConvertableFromA { ... } 
0
source

creating a utility utility class might be better, because if you think about it, the conversation has nothing to do with the object / instance.

for example, when you convert an array to a list, you do not do arr.asList (), rather, you use Arrays.asList (arr)

0
source

Source: https://habr.com/ru/post/1390294/


All Articles