what is encapsulation in an interface ?

[gk]

what is encapsulation in an interface ?


interface Bicycle {

void changeCadence(int newValue); // Do you call this
encapsulation ?

void changeGear(int newValue); // Do you call this
encapsulation ?

void speedUp(int increment); // Do you call this
encapsulation ?

void applyBrakes(int decrement); // Do you call this
encapsulation ?
}

 

[Roedy Green]

what is encapsulation in an interface ?

Encapsulation in carving off a bit of functionality and giving it a
name, rather than repeating the pattern many times in the code.

This way you have only one place to change. You can be sure it is
done consistently, and your program is smaller.
--
Roedy Green Canadian Mind Products
http://mindprod.com
A short order cook is a master of multitasking. Every movement is
optimised from years of practice. Yet when a computer executes a
multitasking program, it approaches the task as if for the first time.

 

[Lew]

what is encapsulation in an interface ?


interface Bicycle {

void changeCadence(int newValue); // Do you call this
encapsulation ?

void changeGear(int newValue); // Do you call this
encapsulation ?

void speedUp(int increment); // Do you call this
encapsulation ?

void applyBrakes(int decrement); // Do you call this
encapsulation ?
}

Encapsulation means that functionality is entirely enclosed within a thing,
and that details of that functionality are hidden from clients outside that thing.

I do not see how the term applies to an interface /per se/. Interfaces do not
contain any functionality to encapsulate. The encapsulation is in the
implementation classes of that interface type. Each different implementor
encapsulates its implementation; clients of the type (the interface and its
subtypes, that is) do not concern themselves (much) with details of the
implementation.

Perhaps it breaks encapsulation, but non-functional implementation
characteristics can determine the choice of implementation type for an
interface. For example, the performance characteristics of 'TreeList' and
'ArrayList' differ, although both encapsulate implementations of 'List'. That
difference could drive the choice of which 'List' to use.

However, as stated your question is difficult to make sense of. I wouldn't
say exactly that there is "encapsulation in an interface" but in the
implementing classes.

What exactly are you trying to figure out and why?

 

[Stefan Ram]

what is encapsulation in an interface ?

The same as »encapsulation« in the general OOP sense,
but using an interface in the sense of Java.

 

[Roedy Green]

what is encapsulation in an interface ?

see http://mindprod.com/jgloss/encapsulation.html
http://mindprod.com/jgloss/interface.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
A short order cook is a master of multitasking. Every movement is
optimised from years of practice. Yet when a computer executes a
multitasking program, it approaches the task as if for the first time.

 

[Tom Anderson]

(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.)

Ahem:

return x.size() - Collections.frequency(x, null);

tom

 

[Lew]

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.

It also pays to be sensitive to when "obvious" is actually a reflection of
dogma or habit.

 

[Lew]

You need less detailed knowledge of the API library to know what it

Any argument that justifies by promoting ignorance of the API is thereby
fatally flawed.

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.

Clarity of "intent" is a specious argument, akin to debating how many angels
can dance on the head of a pin. We can and should presume that "any Java
novice who has gotten past the for-loop chapter of his Java 101 textbook"
would be familiar with the collections API and with 'for' loops, so that
washes out. (Any self-described "Java programmer" who does not /at least/
work to keep up to date /at least/ with the collections API is a saboteur, a
bounder, a poseur and a thief.)

The API approach is less likely to have bugs, generally, than the hand-written
loop approach. That alone justifies it. In the real-world example of a
production system employing professional-pay-grade developers that I cited
earlier, the 'for' loop was complex and bug-ridden. My colleague's rewrite
using 'Set#retainAll()' was bug-free and easy to confirm that it was so. If
'for' loops were equivalently reliable, how did that happen?

 

[Arne Vajhøj]

[...]
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.

That will obviously depend on the size of the collection. What if it's
quite small?

Then performance does not matter.

Arne

 

[Arne Vajhøj]

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.

I don't know. A tight for loop that clearly and directly expresses the
intent, versus a method call that counts nulls rather than non-nulls, and
a subtraction, and another method call?

The for loop expresses the implementation not the intent.

Showing intent and hiding implementation is usually considered
to be good.

Arne

 

[Arne Vajhøj]

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

 

[Arved Sandstrom]

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

 

[Stefan Ram]

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.)

 

[Arne Vajhøj]

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

 

[Lew]

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]

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.

 

[Arne Vajhøj]

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

 

[Stefan Ram]

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="Fancy+algorithms+are+slow+when+n+is+small,+and+n+is+usually+small."

 

[Arved Sandstrom]

[ 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

 

[Lew]

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.