Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Interface design question

Reply
Thread Tools

Interface design question

 
 
Martha Goys
Guest
Posts: n/a
 
      10-26-2004
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
 
Reply With Quote
 
 
 
 
Oscar kind
Guest
Posts: n/a
 
      10-26-2004
Martha Goys <(E-Mail Removed)> wrote:
> 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.


--
Oscar Kind http://home.hccnet.nl/okind/
Software Developer for contact information, see website

PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2
 
Reply With Quote
 
 
 
 
Alex Hunsley
Guest
Posts: n/a
 
      10-26-2004
Martha Goys wrote:
> 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/creat...y/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



 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      10-27-2004
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.



--
Framsticks. 3D Artificial Life evolution. You can see the creatures
that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
me). http://www.frams.alife.pl/


 
Reply With Quote
 
John C. Bollinger
Guest
Posts: n/a
 
      10-27-2004
Martha Goys wrote:
> 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
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Martha Goys
Guest
Posts: n/a
 
      10-28-2004
Martha Goys wrote:
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Interface design question bvssatish@gmail.com C++ 4 10-19-2012 07:27 PM
Dynamic user interface design question MK ASP .Net 0 11-30-2006 06:19 PM
Interface Design Question Michael De Tomaso HTML 3 03-17-2005 06:32 AM
interface design question Rajarshi Guha Java 6 12-09-2004 10:05 PM
PCI interface or USB interface David Wireless Networking 4 09-16-2004 01:01 PM



Advertisments