Design patterns and conventions for object conversion

Question

What is the preferred method of the two below, when it comes to object conversion?

Object conversion using an asX() method

public class Foo {
  int foo;
  public Bar asBar() {
    return new Bar(foo);
  }
}

class Bar {
  int bar;
  public Bar(int bar) {
    this.bar = bar;
  }
}

Object conversion using a constructor

public class Foo {
  int foo;
}

class Bar {
  int bar;
  public Bar(int bar) {
    this.bar = bar;
  }

  public Bar(Foo foo) {
    this.bar = foo.foo;
  }

}

I'm not sure of the merits of either method (with regards to maintainability, scalability et.c), compared to the other. What is the established standard?

I accepted that the question is quite broad as pointed out by Paul Boddington in the comments, but hope for some useful discussion before this question is closed.

You should put the responsibility of conversion in a different object. What if you wanted to convert `Foo` to another type other than `Bar` aswell? You end up with a bunch of conversion methods in your class. Not only this, it'll violate the O/C principle if you later decide to add other conversion methods. — Vince, Mar 20 '16 at 01:33
In addition to the 3 approaches suggested so far, you could also have a `static` method to do the conversion. I think this question is really broad, and there is no right answer. — Paul Boddington, Mar 20 '16 at 01:44
@VinceEmigh Wouldn't that clutter the namespace by introducing a class that is solely used for conversion between objects. I makes sense to me to put such conversion methods in either of the classes that are being converted to/from. — SamTebbs33, Mar 20 '16 at 01:54
This is really broad question, and no context here. If Bar’s kindly of VO and only use for Bar’s conversion. Second is better. And if both bar and foo are Entity objects and totally depend. I suggest use other stateless server method to do this conversion. — Bensson, Mar 20 '16 at 02:02
Not at all. That would be like saying `FileReader` and `FileWriter` clutter the namespace, and their behaviors should be placed directly in the `File` class. It abides by the Single Responsibility principle. Then again, it really all depends on your application's requirements. — Vince, Mar 20 '16 at 02:16
@SamTebbs33, have a look at this SE question : http://stackoverflow.com/questions/34280716/how-to-prune-an-object-of-some-of-its-fields-in-java — Ravindra babu, Mar 20 '16 at 07:58

Tyrel · Accepted Answer · 2016-03-20T02:47:05.100

What I've seen used a lot and I personally like is the style used by a lot of the JDK itself, which involves a static factory method in the destination class. The ultimate goal is to make the code easy to read.

For example:

Integer.fromString("42")

Lending from the example in the OP:

public class Foo {
  int foo;
}

class Bar {
  int bar;

  public static Bar fromFoo(Foo foo) {
    return new Bar(foo.foo);
  }

  public Bar(int bar) {
    this.bar = bar;
  }

}

That way someone can create a Bar from a Foo and the code reads well when doing so:

Bar bar = Bar.fromFoo(foo);

It reads almost like English, without being COBOL!

Design patterns and conventions for object conversion

1 Answers1