Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > what is encapsulation in an interface ?

Reply
Thread Tools

what is encapsulation in an interface ?

 
 
Arne Vajhøj
Guest
Posts: n/a
 
      01-01-2011
On 31-12-2010 15:38, Lew wrote:
> Ken Wesson wrote:
>>> (In reality there's not much reason to have multiple implementations of
>>> countNonNulls; *obviously* it'll be "int i = 0; for (Object o : x) if
>>> (o ! =
>>> null) i++; return i;". But it serves as a quick example.)

>
> Tom Anderson wrote:
>> Ahem:
>>
>> return x.size() - Collections.frequency(x, null);

>
> tom highlights a very important and, at least by me, all-too-overlooked
> phenomenon, to whit, the ongoing development of the collections framework.
>
> So much stuff has been added since Java 5 (such as the cited
> 'Collections.frequency()') and since 6 that really simplifies and
> enhances coding power and expressiveness. A colleague at work was just
> waxing rhapsodic yesterday about the power of the 'Set' interface.
> ('retainAll()' was the specific focus of his adoration, which actually
> has been around for a long time. Somehow his predecessor maintainers of
> that particular module had missed it, though, and hadn't really done a
> very good job of reinventing it, either.)
>
> They don't make as much fanfare about the work on collections as about
> other areas (generics, for example, which are largely motivated by their
> potentiation of collections), but it's arguably some of the most
> significant improvement to the Java platform.
>
> It pays to review the collections API frequently for such gems.


And note that pays is quite literally.

Code logic cost money to maintain.

Every time some code logic can be replaced by Java API, then
it reduces cost.

Things can get a bit more maybe if it is a third party library, because
dependencies on such also cost, but Java API is already in use.

Arne
 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      01-01-2011
On 11-01-01 01:33 PM, Arne Vajhøj wrote:
> On 01-01-2011 04:28, Ken Wesson wrote:
>> On Sat, 01 Jan 2011 00:58:48 -0800, Peter Duniho wrote:
>>> On 12/31/10 11:04 PM, Ken Wesson wrote:
>>>> [...]
>>>>> really simplifies and enhances coding power and expressiveness.
>>>>
>>>> I think my for loop is a bit clearer (and probably runs quite a bit
>>>> faster) than Tom's code.
>>>
>>> Why is it clearer?

>>
>> You need less detailed knowledge of the API library to know what it
>> means, for one thing.

>
> If writing your own code instead of using a standard API is a good
> thing in general, then we can reduce the size of Java API a lot. But
> the we have ti rewrite all those books about software development that
> praises reuse. Lot of work.
>
> Or maybe ...
>
>> If you know, or can guess, that the for loop
>> iterates over the collection, it's pretty obvious.
>>
>> Perhaps if "frequency" was better named, say as "count", that wouldn't be
>> the case.

>
> Frequency is a common English word.

[ SNIP ]

Except that frequency is relative. A temporal frequency is a count
relative to a unit/period of time. A spatial frequency is a count
relative to a unit of distance. And so forth.

Count by itself - and counting the number of non-nulls in a collection
qualifies - is absolute. There's no reference here. It's a count, and
they should have called the method "count".

AHS
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      01-01-2011
=?UTF-8?B?QXJuZSBWYWpow7hq?= <(E-Mail Removed)> writes:
>>I think my for loop is a bit clearer (and probably runs quite a bit
>>faster) than Tom's code.

>Both are O(n) so it would be very surprising to see any
>measurable difference.


The runtimes of two implementations of the same algorithm
may still differ by a significant factor. (Optimizations in
this regard, therefore, are also known as factor optimizations.
They do not change the O(...) complexity type, but might still matter.)

 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      01-01-2011
On 01-01-2011 12:57, Arved Sandstrom wrote:
> On 11-01-01 01:33 PM, Arne Vajhøj wrote:
>> On 01-01-2011 04:28, Ken Wesson wrote:
>>> On Sat, 01 Jan 2011 00:58:48 -0800, Peter Duniho wrote:
>>>> On 12/31/10 11:04 PM, Ken Wesson wrote:
>>>>> [...]
>>>>>> really simplifies and enhances coding power and expressiveness.
>>>>>
>>>>> I think my for loop is a bit clearer (and probably runs quite a bit
>>>>> faster) than Tom's code.
>>>>
>>>> Why is it clearer?
>>>
>>> You need less detailed knowledge of the API library to know what it
>>> means, for one thing.

>>
>> If writing your own code instead of using a standard API is a good
>> thing in general, then we can reduce the size of Java API a lot. But
>> the we have ti rewrite all those books about software development that
>> praises reuse. Lot of work.
>>
>> Or maybe ...
>>
>>> If you know, or can guess, that the for loop
>>> iterates over the collection, it's pretty obvious.
>>>
>>> Perhaps if "frequency" was better named, say as "count", that
>>> wouldn't be
>>> the case.

>>
>> Frequency is a common English word.

> [ SNIP ]
>
> Except that frequency is relative. A temporal frequency is a count
> relative to a unit/period of time. A spatial frequency is a count
> relative to a unit of distance. And so forth.


Usually - yes.

Even though http://en.wikipedia.org/wiki/Statistical_frequency actually
do mention the concept of "absolute frequencies".

> Count by itself - and counting the number of non-nulls in a collection
> qualifies - is absolute. There's no reference here. It's a count, and
> they should have called the method "count".


I would not consider it a problem if SUN had decided to call
the method count.

But I think frequency is still understandable.

Arne




 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      01-01-2011
Ken Wesson wrote:
>>> I think my for loop is a bit clearer (and probably runs quite a bit
>>> faster) than Tom's code.


Arne Vajhøj wrote:
>> Both are O(n) so it would be very surprising to see any
>> measurable difference.


Stefan Ram wrote:
> The runtimes of two implementations of the same algorithm
> may still differ by a significant factor. (Optimizations in
> this regard, therefore, are also known as »factor optimizations«.
> They do not change the O(...) complexity type, but might still matter.)


I know I'm preaching to the choir, but this conversation about performance has
to be read carefully. Stefan, for example, was precise in his statement, "The
runtimes ... might still matter." The dicey part is knowing if they do
matter, and then which solution works better for various metrics of better.

Performance optimization is notoriously difficult to predict. I'm no expert,
but I've participated in both large and small performance investigations and
the pundits absolutely have the right of it. One must measure, and be clear
about specific performance goals under clearly delineated system loads.

A statement like "my for loop ... probably runs quite a bit faster than Tom's
code [that uses standard API calls]" is ill founded on two counts, the
"probably" and the "runs quite a bit faster". It's also meaningless outside a
context of a particular application server profile.

We can impute a desktop profile from the mention of Swing APIs, so OK there.
But even without looking at the specific implementation of the specific API
calls, I can guess that at worst they encapsulate pretty much the same 'for'
loop. For desktop scenarios where relative performance matters, HotSpot would
drown the differences imposed by an extra method call. At best the API uses
what it uses so many places, delegates to native calls that are pretty damn
fast and "probably" will outperform one's own Java code "quite a bit".

Which difference under contemplated use loads might also be erased by HotSpot.
I don't know.

--
Lew
Ceci n'est pas une pipe.
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      01-01-2011
Lew wrote:
> We can impute a desktop profile from the mention of Swing APIs, so OK there.


It is true that there was no such mention, but I imputed one for pedagogical
reasons. If you don't like the example of a desktop profile, plug in a
different scenario of your preference. The argument is general.

--
Lew
Ceci n'est pas une pipe.
 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      01-01-2011
On 01-01-2011 13:10, Stefan Ram wrote:
> =?UTF-8?B?QXJuZSBWYWpow7hq?=<(E-Mail Removed)> writes:
>>> I think my for loop is a bit clearer (and probably runs quite a bit
>>> faster) than Tom's code.

>> Both are O(n) so it would be very surprising to see any
>> measurable difference.

>
> The runtimes of two implementations of the same algorithm
> may still differ by a significant factor. (Optimizations in
> this regard, therefore, are also known as factor optimizations.
> They do not change the O(...) complexity type, but might still matter.)


True - it can.

But it is not that likely that a x2 in some operation really
will affect overall performance.

Going from O(n) to O(n^2) and data size x100 is something
that is a lot more likely to affect overall performance.

Arne

 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      01-01-2011
Arne Vajhj <(E-Mail Removed)> writes:
>Going from O(n) to O(n^2) and data size x100 is something
>that is a lot more likely to affect overall performance.


http://google.to/search?q=%22Fancy+a...ally+small.%22

 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      01-02-2011
On 11-01-02 04:57 AM, Ken Wesson wrote:
> On Sat, 01 Jan 2011 10:53:15 -0500, Lew wrote:

[ SNIP ]

>> Other than that, the discussion seems to be a matter of style. It is
>> certainly plausible that the library method would have better
>> performance than the hand-written 'for' loop, as the java[x].* APIs have
>> the benefit of close cooperation with the JVM implementation, so an
>> argument based on performance is a no-go.

>
> I don't agree. It's very unlikely that Collections.frequency is anything
> other than an ordinary Java method that gets no special help from the
> implementation. It is certainly unlikely to be native (and if it was, JNI
> call overhead would probably make it SLOWER for all but the largest
> collections).

[ SNIP ]

I'm basically neutral in this discussion so far, but I have to agree
with you (Ken) insofar as I disagree with the blanket statement that
"java[x].* APIs have the benefit of close cooperation with the JVM
implementation".

"Close cooperation"? And hence implicitly better performance? I don't
get that at all. Moving on from Ken's observations, and looking at
_human_ cooperation, I have strong doubts that just because a developer
working on the Collections API is more strongly related, officially, to
a JVM developer, than a third-party programmer, that we're typically and
commonly getting tighter, faster, more reliable code because of it.

I think the benefits to be had are those that you'd expect from any
library that gets used enough. Lots of eyeballs, lots of testing.
Period. There's nothing intrinsically special about the java[x] APIs -
Sun (and now Oracle) didn't/doesn't employ all Josh Bloch's to write
that stuff. In no few cases the java[x] API designs are mediocre, and
always have been - it's not all superstars writing this code.

AHS
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      01-02-2011
Ken Wesson wrote:
> I seem to recall we were discussing expressiveness in Java.

....
> I think you might be surprised at how fast Clojure can be. And how cheap
> the creation of "a whole new collection object" is in this case. Clojure
> has lazy sequences, so the (remove null (...)) is not going to copy
> everything, just end up walking a pointer through the backing collection
> that skips over the null elements behind the scenes.


I seem to recall we were discussing expressiveness in Java.

--
Lew
Ceci n'est pas une pipe.
 
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
Transaction based testbench - Effective encapsulation of the client 'transactors'? Andrew FPGA VHDL 14 10-05-2005 07:40 PM
Does 2811 fast ethernet interface support ISL encapsulation? willie Cisco 1 07-20-2005 11:10 AM
"Encapsulation failed" when trying to send on VPDN interface. Yehavi Bourvine Cisco 0 08-01-2004 04:47 PM
TCP over IPSEC NAT encapsulation anth0 Cisco 0 12-18-2003 01:19 PM
question about encapsulation for ethernet ? brian Cisco 1 11-28-2003 04:23 PM



Advertisments