Interface design question

[Martha Goys]

I may be over-thinking this, but had a question regarding best design of
a interface. The function of this interface is very simple: take an
object and produce another object from it (input and output are
different types, but this is not important here).

I'm debating on one of the following approaches:

A)
SomeClassA getOutput(SomeClassB input)

or

B)
void setInput(SomeClassB input)
SomeClassA getOutput()

The plus I see with approach A is its simplicity, and that the flow is
very obvious.

The pluses I see with approach B is the use of bean syntax, which is
very useful in reflection, etc.

I suppose what's throwing me is that since this is currently just an
interface, it's hard to see if there's really much difference in the two
approaches above.

Any words of wisdom?


Thanks,

M

 

[Oscar kind]

I'm debating on one of the following approaches:

A)
SomeClassA getOutput(SomeClassB input)

or

B)
void setInput(SomeClassB input)
SomeClassA getOutput()

The plus I see with approach A is its simplicity, and that the flow is
very obvious.

The pluses I see with approach B is the use of bean syntax, which is
very useful in reflection, etc. [...]

Any words of wisdom?

I don't know about wisdom, but I prefer bean syntax only when
getting/setting properties (that's what is was designed for, I believe).

This is not the case here: it is a transformation. So for me, approach A
is the clear winner. But I would make a small change to the method name:

SomeClassA createOutput(SomeClassB input);

Reason: I prefer names that don't resemble getter/setter names for methods
that are not getters/setters.

 

[Alex Hunsley]

I may be over-thinking this, but had a question regarding best design of
a interface. The function of this interface is very simple: take an
object and produce another object from it (input and output are
different types, but this is not important here).

I'm debating on one of the following approaches:

A)
SomeClassA getOutput(SomeClassB input)

or

B)
void setInput(SomeClassB input)
SomeClassA getOutput()

The plus I see with approach A is its simplicity, and that the flow is
very obvious.

The pluses I see with approach B is the use of bean syntax, which is
very useful in reflection, etc.

I suppose what's throwing me is that since this is currently just an
interface, it's hard to see if there's really much difference in the two
approaches above.

Any words of wisdom?

If you're not steering towards bean use currently, then I would
definitely go for a).
You may want to check out the Factory pattern - it might be applicable here.

http://gsraj.tripod.com/design/creational/factory/factory.html

(Functionally, making it a factory won't change much; but to others
coming along and seeing the code, a SomethingFactory might be familiar
and aid understanding.)

alex

 

[Thomas G. Marshall]

Martha Goys coughed up:

I may be over-thinking this, but had a question regarding best design
of a interface. The function of this interface is very simple: take
an object and produce another object from it (input and output are
different types, but this is not important here).

I'm debating on one of the following approaches:

A)
SomeClassA getOutput(SomeClassB input)

or

B)
void setInput(SomeClassB input)

AKA "mutator" or "setter".

SomeClassA getOutput()

AKA "accessor" or "getter".

The plus I see with approach A is its simplicity, and that the flow is
very obvious.

The pluses I see with approach B is the use of bean syntax, which is
very useful in reflection, etc.

I suppose what's throwing me is that since this is currently just an
interface, it's hard to see if there's really much difference in the
two approaches above.

Any words of wisdom?

The fact that it is "just an interface" is a red herring---ignore this
thought forming in your noggin . All interfaces are ultimately part of
an object (somewhere) 's design and so the design of your interface should
reflect
/what is needed by the implementing object/.

So the real question is this: Do you want the implementing object's state
to be mutated with a passed in new object or not? If so, then the
mutator/accessor is the clear winner.

If, instead, you wish this to represent a utility method that implementing
objects must supply, a method that does nothing to the implementing object's
state (it neither stores the newobject, or changes itself based upon
newobject), then approach A is the winner.

 

[John C. Bollinger]

I'm debating on one of the following approaches:

A)
SomeClassA getOutput(SomeClassB input)

or

B)
void setInput(SomeClassB input)
SomeClassA getOutput()

The plus I see with approach A is its simplicity, and that the flow is
very obvious.

The pluses I see with approach B is the use of bean syntax, which is
very useful in reflection, etc.

I suppose what's throwing me is that since this is currently just an
interface, it's hard to see if there's really much difference in the two
approaches above.

In addition to the points raised by the other responses, I'll point out
that option (A) is thread-safe with respect to implementations of the
interface [with a few caveats], whereas option (B) definitely requires
external synchronization to be thread-safe. In general, local variables
are a big win over instance variables (or worse, static variables) when
it comes to thread-safety.


John Bollinger
(e-mail address removed)

 

[Martha Goys]

I may be over-thinking this, but had a question regarding best design of
a interface. The function of this interface is very simple: take an
object and produce another object from it (input and output are
different types, but this is not important here).

I'm debating on one of the following approaches:

A)
SomeClassA getOutput(SomeClassB input)

or

B)
void setInput(SomeClassB input)
SomeClassA getOutput()

The plus I see with approach A is its simplicity, and that the flow is
very obvious.

The pluses I see with approach B is the use of bean syntax, which is
very useful in reflection, etc.

I suppose what's throwing me is that since this is currently just an
interface, it's hard to see if there's really much difference in the two
approaches above.

Any words of wisdom?


Thanks,

M

Many thanks Alex, John, Oscar, and Thomas - this is all very good
information, and helps me quite a bit.


Thanks again,

M