• (cs) in reply to LordHunter317

    LordHunter wrote: "And when you consider that the only difference between an interface and a class is that the former can only declare methods, you realize the former definition is full encasuplated by the latter, as such, it's a touch foolish to define MI solely by the latter."

    So, if a more generic definition exists for something, it is "foolish" to use a more specific one?  I suppose that, too, is a matter of opinion.


  • (cs) in reply to Blue

    In this case, Yes, it is foolish because the more specific definition doesn't cover all cases being discussed.

  • (cs) in reply to LordHunter317

    Well, seems to me you're no Java guru either. (Also, you should stick your tongue in your cheek more often, just to get a feeling for it.)

    LordHunter:

    It's less vague when you're only interested in specfying behaviors, not data and behaviors, since an interface cannot specify data.  It's just syntactical sugar, really.

    I guess the interface construct is useful because if all you had were abstract base classes, designers would be tempted to specify data as well as just methods.  Which is frequently not desirable.  Hence, we have interfaces, where data is disallowed.


    More likely the interface is just what it states to be, an interface. If your class implements an interface you sort of say "I do offer these operations, you can call me on that." That's it.
    LordHunter:

    See the WindowListener/WindowAdapter example above.  The fact that a class exists implementing "default" functionality for an interface tells me the interface doesn't need to exist, as what the interface models is made implict by the class anyway. 


    Doing nothing is NOT the default functionality for any registered Listener; if it was, why register it anyway? The Adapter exists solely for those cases you're not interested in all events this Listener recieves.
    LordHunter:

    finix:

    And what's that "object construct" you're talking of?

    I was refering specifically to classes and interfaces.  In other langauges, anything a class can inherit from would be included.

    Yes, that's a lot clearer now. I thought you were refering to objects.

    LordHunter:

    finix:

    As far as I remember, there are no "interface-objects" - just objects of classes possibly implementing some interface(s).

    You can create a variable of an interface type though, and then only have access to the methods the interface stated

    Yes. But that's still no object. That's your famous "pointer", or your "reference" in Javaspeak.
    (Besides, that's one of the nifty thing about interfaces: you have, e.g., some interface modeling some container, and you can - unless you're a bad boy and cast all the time, in which case your design sucks anyway - exchange the actual type of the container without leafing to every single line of codes adjusting it. Or accept in your methods any container that implements that interface.)
    LordHunter:

    finix:

    Would you really prefer to be forced to derive from WindowAdapter or whatever Listener you might need to extending a class of your choice?

    I'd rather just have the Adapter and be forced to use anonymous inner classes.  For events anyway, it reduces the amount of code I have to write.   The only clear advantage interfaces give you is that you don't have to use inner classes, but the reality of Java is that you will anyway because it makes your code more managable and extensible. 

    I'm not really sure what you're talking about. You'll have some class anyway. And in fact, I find it more useful to have inner classes when the class is of absolutely no use to anything else outside of the class.
    LordHunter:

    FWIW, this goes back to "Design-by-contract" programming, which is a good thing.  But people seem to think that "Design-by-contract" can only be met by interfaces.  This isn't true at all.  It can also be met by abstract classes and regular classes.


    FYI, "Design-by-contract" is more about pre- and postconditions.

    LordHunter:

    (Foo with only pure virtual methods)
    At the very least, the different in name (interface vs. class) makes my intent clear with what I'm creating.

    If you can't see the intent of the code, well... better not comment it. Or just wait - good idea, comment it, or make it a struct so you see straight away that's no ordinary class.
  • (cs) in reply to finix
    finix:
    Well, seems to me you're no Java guru either.
    You'll kindly have to point to where I claimed that.

    More likely the interface is just what it states to be, an interface.
    This shows you missed the point: the interface is a completely redundant construct.  All of it's abilites are already covered by other language constructs. 

    So the question then becomes: why are interfaces important enough to get a special construct?  And the answer is: because modeling behaviors on disjoint sets of data is useful.  But that's the only reason, and it doesn't imply (or even suggest) that interfaces should be used where another construct (e.g., ABT or a plain class) is more appropriate.

    Doing nothing is NOT the default functionality for any registered Listener; if it was, why register it anyway? The Adapter exists solely for those cases you're not interested in all events this Listener recieves.
    (emphasis mine).  So what do we call doing something automatically without any input?  That's right: a default.  . 

    And, unless you can come up with a case where the Adapter's default behavior is incorrect, I'd argue the interfaces should go away completely, because they are redundant.  For the specific case of Java event-handling, I don't think such a case exists.  This is the crux of my point.

    Yes. But that's still no object. That's your famous "pointer", or your "reference" in Javaspeak.
    Yes, and it's a reference to an object.  If you want to follow that line of argument, then all I have in java are references and primitive types, it's impossible to have an object, ever.  I'm afraid this reasoning is invalid.

    Since interfaces are part of the class (object) hiearchy, they should be considered objects.  If this were C++, we wouldn't even be having this discussion.

    (Besides, that's one of the nifty thing about interfaces: you have, e.g., some interface modeling some container, and you can - unless you're a bad boy and cast all the time, in which case your design sucks anyway
    Or you're using Java or C# and such casts are foisted on you by the shitty API.
  • (cs) in reply to LordHunter317
    LordHunter:

    finix:

    Well, seems to me you're no Java guru either.

    You'll kindly have to point to where I claimed that.

    I know it sounds absurd, but there actually are conclusions that don't result from assertions of the opposite. Anyway, no offence meant.
    LordHunter:

    finix:

    More likely the interface is just what it states to be, an interface.


    This shows you missed the point: the interface is a completely redundant construct.  All of it's abilites are already covered by other language constructs. 

    Beg your pardon, but I dare to disagree. The interface is NOT completely redundant, especially since Java does not have - classwise - multiple inheritance. That's for all abilities covered by other language constructs, but it goes on: it adds an ability to an other language construct, namely class. Moreover, it's semantically different from class.

    As for the WindowListener issue, it seems this time you missed my point. If you register an Listener you sort of state "I am interested in Window events". The adapter is only for cases you're not interested in all of them; it spares you a few lines of code. And no, deriving from WindowAdapter and implementing WindowListener is not the same, so there's no redundancy - if at all, the adapter is redundant, and surely wouldn't exist wasn't it such a commonly used utility.

    LordHunter:

    finix:

    Yes. But that's still no object. That's your famous "pointer", or your "reference" in Javaspeak.


    Yes, and it's a reference to an object.  If you want to follow that line of argument, then all I have in java are references and primitive types, it's impossible to have an object, ever.  I'm afraid this reasoning is invalid.

    I'm afraid to disappoint you, but this reasoning is everything but invalid.
    For one thing, a reference to an object isn't the same as the object itself. For another, any object you're refering to, be it via class or interface, is an object of a concrete class; there's neither objects of abstract classes nor interfaces.
    LordHunter:

    Since interfaces are part of the class (object) hiearchy, they should be considered objects.  If this were C++, we wouldn't even be having this discussion.


    I'll wager we'd have, too, as classes and objects aren't exactly the very same thing.
    LordHunter:

    finix:

    (Besides, that's one of the nifty thing about interfaces: you have, e.g., some interface modeling some container, and you can - unless you're a bad boy and cast all the time, in which case your design sucks anyway.


    Or you're using Java or C# and such casts are foisted on you by the shitty API.


    If you're hinting at collections prior to Java 1.5 you didn't catch my drift.
  • (cs) in reply to finix
    finix:
    Beg your pardon, but I dare to disagree. The interface is NOT completely redundant, especially since Java does not have - classwise - multiple inheritance.
    Yes, this is specifically true of Java.  But in the general sense, a specific interface construct is redundant.

    Which is why all the interfaces exist in Java, even when they are really redudnant in reality.

    As for practical matters, it turns not not having classwise multiple inheritance isn't a big deal because you tend not to implement a ton of interfaces in the same class anyway.  You almost always use an inner class or an anoymous class, because it makes the code more modular and manageable (and worlds uglier [:S]).  So even in practical terms, the interface construct even in Java could be done away with (not that I'm advocating it should be, but it certainly could be).  The fallout: that inner classes must be used in cases where they wouldn't have to be before, doesn't seem like a huge problem to me because they were likely to be used anyway.  If anything, it could be a plus, not a minus.

    As for the WindowListener issue, it seems this time you missed my point. If you register an Listener you sort of state "I am interested in Window events". The adapter is only for cases you're not interested in all of them; it spares you a few lines of code.
    Right, meaning it's providing default functionality for every event you're not interested in.  Which means by consequence, if this default functionality is correct for every case where the interface is used, the interface must be redudant.  Remember, the only difference between the Listener and it's Adapter (ignoring pesky class v. interface inheritence rules) is the fact the Adapter has a bunch of implementations that do nothing and the Listener does not.

    And no, deriving from WindowAdapter and implementing WindowListener is not the same,
    But if WindowAdapter covers all cases where I'd use WindowListener, then it surely is.

    if at all, the adapter is redundant
    You're thinking about it backwards.  The Adapter cannot be redundant; it is a more complete specification of the interface.  The interface can be redundant if and only if all cases where it is used could be substituted by use of the Adapter instead.  I'm suggesting that in the case of Java events, this is very much true; the more complete Adapter specification is fully interchangable for the less complete Listener specification (because everyone meets the extra requirements of the Adapter).  Ignoring the interface vs. class stupidity, of course.

    For one thing, a reference to an object isn't the same as the object itself
    In Java it certainly is.  Classes don't have value-type semantics.  I can only access a class via a reference.

    For another, any object you're refering to, be it via class or interface, is an object of a concrete class; there's neither objects of abstract classes nor interfaces.
    I don't believe that disqualifies calling an interface an "object type" (or construct).  What you're saying is that the ability to instantiate is a requirement to call something an object type.  I don't believe that's true, if it were, languages would use a different keyword for all abstract types.  I think the only requirement to consider something an object type is that it must have the ability to be inherited from.  Interfaces and ABCs certainly fit that description.  Final classes do too, as they normally have that ability, but it's been explictly disabled (OK, they're a slight strech ;) ). 
    Once again, I maintain if this were C++ and not Java, we wouldn't even be having this discussion.

    I'll wager we'd have, too, as classes and objects aren't exactly the very same thing.
    This is because C++'s definitions are funny  with regard to the rest of the world.

    If you're hinting at collections prior to Java 1.5 you didn't catch my drift.
    No, I caught it, but even post Java 5, the language still foists the requirment to cast upon you.   Java 5 just goes a long distance to minimize how often these casts must occur.
  • (cs) in reply to LordHunter317

    My last post on this issue:

    Classes are constructs which contain methods, delegates, properties, and variables.  They must be instantiated to be used (except Const and Static members, of course).

    In Java / C#, a given Class can directly INHERIT from exactly one CLASS.  They can IMPLEMENT any number of interfaces.  Therefore, INHERITANCE is SINGLE in that literal definition, which I think you'll find most people agree on.

    Yes, you can achieve the same results as multiple inheritance by utilizing interfaces, but just because there is a workaround, it doesn't make it a language feature.  I consider it to be much like other constructs that are present in non-Java languages, but have a "workaround" to accomplish similar results in Java.  

    Objects are instantiated constructs, and are not the same as classes, interfaces, etc.


    Aside from you, I've never seen anyone try to say that Java or C# support multiple inheritance - they will all (yourself, myself included) agree that you can accomplish a similar result using interfaces, but they won't come out and say that these languages DO support it.  I challenge you to provide a Credible Source(tm) of anyone making such a claim. 



  • (cs) in reply to LordHunter317

    You know, I was just about to reply, but the forum software is still doesn't work properly and frankly I can't be bothered to dismantle your post. I'm getting the hunch you're just pulling my legs anyway, being deliberately obtuse.
    Your first posts I could partly agree with (although that might've been just my bad english or your by times rather obscure way to express yourself) - but this last one, honestly, and still no offence meant (or congratulations, possibly, it's hilarious), is simply bollocks. And phenomenally so, too.

  • (cs) in reply to Blue

    <FONT style="BACKGROUND-COLOR: #efefef">Even the MS docs say that .Net (exception of C++) does not support multiple inheritance. They mention multiple interface inheritance, and say its to avoid unpredicatable results. (Or "Unholy Messes" which is what I generally end up with ;) )</FONT>

    <FONT style="BACKGROUND-COLOR: #efefef">At a low level (afaik) a referance to an interface is basically a pointer into a classes vftable with an offset and a *this (but you dont know what type the *this is).</FONT>

  • (cs) in reply to

    Anonymous:
    Yes, anonymous inner classes are a common way of hacking around this stupid implementation choice, but .Net's delegate approach is much better.

    Actually Listeners are an implementation of the Observer-Observable pattern.  Not a poor implementation choice at all, if you know what you are doing.

    Making your public GUI component implement the listener is WRONG.

    Making inner classes in your GUI class better but still WRONG.

    The only things implementing these interfaces should be Controller classes.  And don't get me started on extending JFrame to add components to it.  Thats wrong too.

    Of course if you don't want to actually understand what you are doing, you can just barf up some .NET.

  • maleu (unregistered)

    the real WTF here is that Java encourages such design.

    how could some poor programmer know better when the official API contains such mess.

  • (cs) in reply to maleu

    Anonymous:
    the real WTF here is that Java encourages such design.

    how could some poor programmer know better when the official API contains such mess.

    Because there is a class is the AWT (WTF) library that does this, it means that Java encourages it? [8-)] I don't think so.  In any event it actually kind of makes sense for that class.  Of course, you'd have to understand what that class does first.

  • anonymous (unregistered) in reply to
    Anonymous:
    The plural of 'knife' is 'knives'.


    No.. it's 'knife []'
  • Mike (unregistered)

    This an example of code that would be much more readable if Java would implement a <FONT color=#0000ff>does_not_implement</FONT> keyword.

    [8-|]

  • abionnnn (unregistered) in reply to Mike

    Or a implements everything keyword =P

  • (cs)

    Let me guess what the method body looks like:

    if(source instanceof Message){
        Message m = (Message)source;
        ///blah blah
    }else if(source instanceof Error){
        Error e = (Error) source;
        ///blah blah
    }else if(source instanceof HelpRequest){
    ....
    you get the idea

Leave a comment on “Implements ISwissArmyKnife”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article