Java Question Best practice for library parameter types?

[agraham]

I'm sure that I knew the answer to this many years ago but the ravages of time have dulled the sharp edges of my previously formidable intellect and I haven't found an answer on the forum so ....

I have just updated a property in ScaleImageView to have a getter as well as a setter. For consistency, as the original setter took a native Bitmap type I have made the getter return the same type. It seems that the compiler can deal with this without problem but in general would it be better practice to return a Wrapper rather than a naked (Ooh matron!) Bitmap?

For non-Brits and those Brits less than a certain age the humorous meme is from one of the Carry On films.

 

[jahswant]

BitmapWrapper bm = new BitmapWrapper();
bm.SetObject(nativebitmap);

 

[agraham]

Of course I know how to do that - have you seen all my contributions over the years? That is nothing to do with the question I asked which is what is best practice.

 

[jahswant]

have you seen all my contributions over the years?

I respect ? them sir. I surely didn’t understand your question ! Sorry ?.

 

[Cableguy]

Hi Andrew...

As you know, I am no expert in this, and I mostly use common sense in such cases...
Ask yourself what would be the most versatile option to the user and what "cost" does it have computational power wise.
I'm sure your intellect is still as formidable as it once was before the ages started cashing you in.

 

[agraham]

Ask yourself what would be the most versatile option to the user and what "cost" does it have computational power wise.

Actually it's invisible to the user/programmer as the compiler seems to be able to cope with both wrapped an unwrapped parameter values. The query is more a matter of style and whether there is some edge case where the compiler can't cope.

 

[Erel]

It is better to return a wrapper. It should be an uninitialized wrapper if there is no bitmap (don't return Null).

It's better because it will be a bit easier for developers to work with.