• Maik (unregistered)

    Now I can't see anything funny about it yet. MMSNode, MMSPhysComp and the others could very well be interfaces, without a common super-interface declaring getAttribs(). Unless that super-interface isn't said to exist it's not really funny.

  • Thomas Eyde (unregistered)

    "Unless that super-interface isn't said to exist it's not really funny."

    If it's not there, create it!

  • DCD (unregistered)

    I don't know what's funnier, the WTF in the example or the WTF in the comments.

  • TJ (unregistered)

    How sad :(

    I mean this is the day of the internet, its not like you have to buy a 50$ book. Read a damn blog or something...Jeeze people wake up.

  • Frans Bouma (unregistered)

    erm...

    what do you guys do when getAttribs is an internal method? You then can't define it in an interface. You can only produce polymorphism if you use a base class with an abstract/virtual method which is overridden in all the MMS classes. If that's not the case (let's say it isn't), this is the only way to do it.

    Now, I'm not saying that not using a common base class if you need a common internal member over several classes is a good thing to do, but perhaps there was a reason for it not to use a common base class, as Java is single inheritance only.

    Most of the time, the code presented here is drop dead horrible, however I can see solid reasons why this code is simply the code that does the job in that particular situation. (we don't know that ;)). Or I miss something completely obvious...

  • Jason (unregistered)

    Yes, Java is single inheritance, but it certainly supports interfaces. Which would accomplish everything necessary in the above example.

    The only way the code makes sense is if the variables got used outside of whatever loop the code exists in, and needed to be casted to the specific type. But since they're declared and initialized inside the loop, that seems highly unlikely.

  • Frans Bouma (unregistered)

    "Yes, Java is single inheritance, but it certainly supports interfaces. Which would accomplish everything necessary in the above example. "

    Not, if java, as C# and VB.NET doesn't allow internal interface members. In C# for example, you have to make your interface members public, you can't implement them as internal. If you don't want your members to be public, you can't use an interface for this. That was my point. I don't know if this is the case here, as we don't have a lot of info in this ;), so it might be the developer is indeed too stupid to mention, but in the case he/she indeed has to deal with limitations in the framework/language at hand, it is not that appropriate to bash this persion to pieces ;)

  • wx (unregistered)

    how about declaring the interface private?

    like

    internal interface IAttribsPvt {}
    and
    public interface IPublic { everything else }

    class X : IPublic, IAttribsPvt
    {
    ...
    }

  • DCD (unregistered)

    Frans - given if what you assume is correct, I'd still rather use reflection to invoke the getattribs method rather than write that ugly if/else condition.

  • Roger (unregistered)

    <b>Not, if java, as C# and VB.NET doesn't allow internal interface members. In C# for example, you have to make your interface members public, you can't implement them as internal. </b>

    pure BS!!!
    C# does support internal interface members ,

    you define them by:

    interfacename.methodname type methodname(params)
    ^ note the interfacename and no modifier

    this is what you get if you for example use "implement interface" in the classview.

    //Roger

  • TheF0o1 (unregistered)

    In the first place, the getAttribs method cannot be private (or "internal" in C# terms, but the "instanceof" keyword leads me to believe this is Java). Otherwise, how would the above code call it?

    In the second place, IMHO, an interface is the appropriate way to support this kind of polymorphism, not a base class (at least in Java).

    In the third place, WTF?

  • Roger (unregistered)

    to clarify , internal as in only visible if the object instance is casted to the interface and not visible on the class implementation. not internal as in the "internal" c# keyword ..

    so please ignore the "bs" part if the later case was the one you ment ;)

  • Roger (unregistered)

    oke back again :P, those pills are making my head spin..
    make the declaration to only show c# members when accessing the interface :
    type interfacename.methodname()

    on the good side , maybe i invented a new wtf snippet with the previous declaration :P

  • Frans Bouma (unregistered)

    "pure BS!!!
    C# does support internal interface members , "
    I know, don't worry about that, but it's not common, and for example doesn't work in VB.NET. (try to inherit a class from Datatable and override the ISerializable members :P you can only do that in C#, with explicit interface implementations).

    "In the second place, IMHO, an interface is the appropriate way to support this kind of polymorphism, not a base class (at least in Java). "
    I agree, although in .NET, MS advices to use (abstract) base classes, not interfaces (dunno why) for most common scenario's.

    Though 'internal' means: public in the assembly, not accessable outside the assembly. I really don't know if Java has that kind of accessor type though :) If not, it's indeed more likely the developer simply didn't have a clue and the WTF is very well deserved :) (someone with java knowledge in the house? :))

  • Mitch Denny (unregistered)

    Sadly I've seen API's that I need to work against in this manner. Quick hacks like these are ideally very localised.

  • Keith Gaughan (unregistered)

    Ok, somebody explain to me the utility of internal interfaces, 'cause I really have to admit that I don't get why they might be considered useful.

  • Richard Wan (unregistered)

    Suppose the developer of the ugly if else code had no access to the MMS source code and was unable to alter that MMS classes to implement a common interface. In that case, it was an adequate (but horrifying) workaround.

    I can think of various reasons this may be the case. The classes which should have a common interface may have come from (multiple) 3rd party vendors, the developer may not have been given sufficient permission to alter the code base containing the MMS classes because they were used by other other teams.

  • Alex Papadimoulis (unregistered)

    I've used them to create interfaces for data providers used only within the assembly. The user was able to specifiy which access provider to use -- various access providers used different sets of interfaces. The client didn't need to know of any of this.

  • KoFFiE (unregistered)

    And how the f*ck could this getAttribs() function be private (or "internal" to please the C# audience)? Think a few secs before you post plz... An object is used inside a function, and in that function you don't know what class it is, but they all have the getAttribs() function... Sounds pritty "external" or "public" stuff to me...

    Also, unless that's passed as a "Object" type, they should all have a same baseclass no? If there are indeed sub-classes of that base-class that don't need attributes, you have 2 options, or you make a dummy-function that returns NULL that should be overridden by the sub-class if it should support it, or you implement a common interface for the classes that need it, as stated, which is more generic.

    Something I also don't understand is why the hell he declares a variable for each class-type he does an instanceof test for, was inline-casting too complicated or complex? This doesn't really help readability like this imho...

  • asdfs (unregistered)

    Fans: well yes, tried to inherit DataTable and override the Dispose() method.
    MS Visual Studio made me do a "WTF"?, because Dispose() seems to be overridable and not overridable at one time:
    http://naivist.net/yesnoOverridable.jpg
    :)))

  • Beginner (unregistered)

    DCD: I totally agree with you! In most of the posts comments are the crazy stuff!

  • David Shay (unregistered)

    To cut short (well, there is already a long list of them) those comments that try to save this code: there actually is a base class for all those MMSes, and yes, it has an abstract getAttribs() method. I had to explain what is polymorphism to the guy who wrote this code. I hope he understands now, else I'll post some more of his code to WTF...

  • Frans Bouma (unregistered)

    david: hehe, ok, thanks for clearing that up! the guy obviously deserved the wtf of the day for 100% :D.

  • ExThoughtWorker (unregistered)

    The sad thing is that I have seen this instanceof anti-pattern more times than I care to remember, written by people who claim to be Java experts.

    It really is sad when the only three reasons that you can come up with for this sort of code are:

    1. The programmers are ignorant and don't understand polymorphism (which seems all too common)
    2. The programmers are too lazy to bother to create the interface/abstract class (which is also far too common)
    3. They are both lazy and ignorant

  • Nick D (unregistered)

    I would've saved a line of code and done this instead:

    attribs = ((MMSNode)obj).getAttribs();

    I think you'll agree, that's MUCH better.

  • ProffK (unregistered)

    Much better - you would even have actually saved four lines of code!

  • Ryan (unregistered)

    Some of these comments are a little weird.


    C# "internal" != Java "private"

    Its closer to "package", but not really.

  • Foobar (unregistered)

    Let me be the first to say... "Do any of you bitches have the spec?"

  • Keith Gaughan (unregistered)

    On Alex's explaination of internal interfaces: Cheers!

  • PKJ (unregistered)

    Why not simply examine the visitor pattern...?

  • DCD (unregistered)

    Regarding "asdf" overriding Dispose of Datatable: you need to override the Dispose(bool disposing) method, not Dispose(). Never override the Dispose() method unless you want to shoot yourself in the foot.

  • Thomas Eyde (unregistered)

    ...because it is not marked "virtual" in this context.

  • AndrewSeven (unregistered)

    Re:To cut short ...

    Are you saying he knew how to write polymorphic code, but not how to use it?

  • easyCoder (unregistered) in reply to Thomas Eyde
    Anonymous:
    "Unless that super-interface isn't said to exist it's not really funny."

    If it's not there, create it!


    If those classes are part of a lib that cannot be altered then this is probably the quickest solution.  "Adding" a common interface is impossible in that case.

    If you hate quick solutions, create wrappers for all those classes that DO implement a common interface.
  • Anonymous Coward (unregistered)

    The obvious way to do it would be:

    Method m = obj.getClass().getDeclaredMethod("getAttribs", new Class[]{});                                             
    attribs = m.invoke(obj, new Object[]{});

    ;)

  • rp (unregistered) in reply to Frans Bouma

    In VB.NT, you can; I use it , too (I have classes in which the only public method is the constructor). One ot the things that make me feel that VB.NET is a slight improvement over C#.

  • (cs) in reply to KoFFiE

    Anonymous:
    And how the f*ck could this getAttribs() function be private (or "internal" to please the C# audience)? Think a few secs before you post plz... An object is used inside a function, and in that function you don't know what class it is, but they all have the getAttribs() function... Sounds pritty "external" or "public" stuff to me...

    While I agree with everything else in the above message, KoFFiE obviously isn't familiar with C# as internal is something very different from private... internal objects are basically public within the assembly (DLL or EXE) in which they are defined, but private and not visible at all outside that assembly

Leave a comment on “Not quite getting that Object-polymorphism thing ...”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article