Is this convenience function ok?

[EdwardH]

class Status has a member class called Transferstatus.

class TransferStatus has the method
setData(filename, filesize, direction)

Normally one would call
Status.getTransferStatus().setData(filename, filesize, direction)

Q: What are y'all's opinions on making a convenience function in Status
that calls setData? Status.set(filename, filesize, direction).


It's much shorter to use Status.set, but are there any disadvantages? Am
I making Status too smart?

 

[Dave Glasser]

class Status has a member class called Transferstatus.

class TransferStatus has the method
setData(filename, filesize, direction)

Normally one would call
Status.getTransferStatus().setData(filename, filesize, direction)

Q: What are y'all's opinions on making a convenience function in Status
that calls setData? Status.set(filename, filesize, direction).

That's the preferred way to do it, according to the Law of Demeter:

http://pragmaticprogrammer.com/ppllc/papers/1998_05.html
(Scroll toward the bottom)

http://www.ccs.neu.edu/home/lieber/LoD.html


--
Check out QueryForm, a free, open source, Java/Swing-based
front end for relational databases.

http://qform.sourceforge.net

If you're a musician, check out RPitch Relative Pitch
Ear Training Software.

http://rpitch.sourceforge.net

 

[EdwardH]

That's the preferred way to do it, according to the Law of Demeter:

Law of Demeter applied.

Thanks for the info.

 

[Wibble]

class Status has a member class called Transferstatus.

class TransferStatus has the method
setData(filename, filesize, direction)

Normally one would call
Status.getTransferStatus().setData(filename, filesize, direction)

Q: What are y'all's opinions on making a convenience function in Status
that calls setData? Status.set(filename, filesize, direction).


It's much shorter to use Status.set, but are there any disadvantages? Am
I making Status too smart?

I'm generally opposed to convenience functions. They seem like a good
idea, but often become an obfuscation layer. Like you said, Status
becomes too smart. When you change TransferStatus, Status has to also
change. Consumers may use either signature, so it becomes less clear;
choice is evil. If you're writing tests, you should now write tests
for both interfaces. I like writing unit tests since the pain of
writing a test has often caused me to delete features that are not
required.

 

[Roedy Green]

It's much shorter to use Status.set, but are there any disadvantages? Am
I making Status too smart?

It is legit in that what you propose doing has a design pattern name
-- Facade. The advantages are:

1. it is easier for your clients. They don't have to remember the
clumsy, and(what feels to them like an), arbitrary, syntax.

2. It gives you flexibility to redesign your innards,
add/delete/rename classes, move functionality around.

One place Sun should have used a Facade was for JComponent.add.
instead of JComponent.getContentPane().add(). The did add it in 1.5.