what is encapsulation in an interface ?

Discussion in 'Java' started by gk, Dec 30, 2010.

  1. gk

    gk Guest

    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 ?
    }
    gk, Dec 30, 2010
    #1
    1. Advertising

  2. gk

    Roedy Green Guest

    On Thu, 30 Dec 2010 03:58:45 -0800 (PST), gk <> wrote,
    quoted or indirectly quoted someone who said :

    >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.
    Roedy Green, Dec 30, 2010
    #2
    1. Advertising

  3. gk

    Lew Guest

    On 12/30/2010 06:58 AM, gk wrote:
    > 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?

    --
    Lew
    Ceci n'est pas une pipe.
    Lew, Dec 30, 2010
    #3
  4. gk

    Stefan Ram Guest

    Re: what is encapsulation in an interface ?

    gk <> writes:
    >what is encapsulation in an interface ?


    The same as »encapsulation« in the general OOP sense,
    but using an interface in the sense of Java.
    Stefan Ram, Dec 30, 2010
    #4
  5. gk

    Roedy Green Guest

    Roedy Green, Dec 31, 2010
    #5
  6. gk

    Tom Anderson Guest

    On Fri, 31 Dec 2010, 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.)


    Ahem:

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

    tom

    --
    Just add a little flange and phase in
    Tom Anderson, Dec 31, 2010
    #6
  7. gk

    Lew Guest

    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.

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

    --
    Lew
    Ceci n'est pas une pipe.
    Lew, Dec 31, 2010
    #7
  8. gk

    Lew Guest

    Ken Wesson wrote:
    > 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?

    --
    Lew
    Ceci n'est pas une pipe.
    Lew, Jan 1, 2011
    #8
  9. 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.

    >> And as for "quite a bit faster", I doubt it is (the subtraction and
    >> extra method call are inconsequential compared to the element
    >> enumeration

    >
    > 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, Jan 1, 2011
    #9
  10. On 01-01-2011 02:04, Ken Wesson wrote:
    > On Fri, 31 Dec 2010 15:38:23 -0500, Lew 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.


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

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

    >
    > 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, Jan 1, 2011
    #10
  11. 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
    Arne Vajhøj, Jan 1, 2011
    #11
  12. 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
    Arved Sandstrom, Jan 1, 2011
    #12
  13. gk

    Stefan Ram Guest

    Re: what is encapsulation in an interface ?

    =?UTF-8?B?QXJuZSBWYWpow7hq?= <> 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.)
    Stefan Ram, Jan 1, 2011
    #13
  14. 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
    Arne Vajhøj, Jan 1, 2011
    #14
  15. gk

    Lew Guest

    Re: what is encapsulation in an interface ?

    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.
    Lew, Jan 1, 2011
    #15
  16. gk

    Lew Guest

    Re: what is encapsulation in an interface ?

    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.
    Lew, Jan 1, 2011
    #16
  17. gk

    Arne Vajhøj Guest

    Re: what is encapsulation in an interface ?

    On 01-01-2011 13:10, Stefan Ram wrote:
    > =?UTF-8?B?QXJuZSBWYWpow7hq?=<> 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
    Arne Vajhøj, Jan 1, 2011
    #17
  18. gk

    Stefan Ram Guest

    Stefan Ram, Jan 1, 2011
    #18
  19. 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
    Arved Sandstrom, Jan 2, 2011
    #19
  20. gk

    Lew Guest

    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.
    Lew, Jan 2, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew FPGA
    Replies:
    14
    Views:
    1,143
    Jim Lewis
    Oct 5, 2005
  2. Jack
    Replies:
    1
    Views:
    476
  3. Wayne Berke
    Replies:
    0
    Views:
    389
    Wayne Berke
    Sep 19, 2003
  4. Tim Jowers

    obj,fn,parms encapsulation in java

    Tim Jowers, Sep 13, 2004, in forum: Java
    Replies:
    1
    Views:
    375
    Alan Meyer
    Sep 13, 2004
  5. Replies:
    1
    Views:
    10,430
    kj12345
    Mar 1, 2005
Loading...

Share This Page