- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
It's a floor wax and a desert topping!!
Admin
That really makes me laugh ... I suppose it is possible that it might REALLY need to implement all these, but .... no it can't be possible. Now, it might be NECESSARY due to some really bad design decisions in the object hierachy of this library, but with a good design this should never happen ... ever hear of inheritence?
(A pre-emptive: yes, VB.NET has iheritence ... no, the WTF isn't just using VB in general ....)
Admin
This is a prime candidate for anonymous inner classes, I know some people hate them but I think they're better than implementing at the main class level thus making all the methods public. I guess it depends on how those interface methods are called.
Admin
Looking at all those listeners.. I wonder if those are all interfaces or not. Also, the question I have is.. why in the world is it written in c# using the keyword "implements" o.O are you sure this is written in vb.net? cuz it also has the { and // comments.
I doubt this even compiled!
Admin
Admin
Oh god damn!
Admin
how many lines of code does it take just to implement the interface members?
Admin
It could be any number of methods betwen 0 and n to implement each interface.
The real WTF is the sheer amount of events that must be firing left and right all over this application.
Admin
He should at least have a "ScheduleChangeListener", that would remove 4 or 5 of them.
Admin
Clearly this is a class made to attract women. Whenever women want to give a man a compliment they say "he's a good listener."
Admin
Lemme guess, all this and I only have to override one method too, right?
Admin
I'm particularly fond of the OKListener.
Admin
[:'(] HAHAHAHAHAHAHAHAHAHAHAHAHA...cough cough... gasp.... MUAHAHAHAHAHAHAHAHAH...Crash.. (fall dead on floor) WTF is this programmer thinking???? Why not just implement every thing and then you would never need to use any other object but yours.
Admin
<FONT style="BACKGROUND-COLOR: #efefef">oops, yes it is C#, not VB.NET .....</FONT>
Admin
Admin
*sigh* It is Java, damnit, and it's a "feature" of java that if you want to listen to an event, you must implement an interface which is <eventname>Listener.
Yes, anonymous inner classes are a common way of hacking around this stupid implementation choice, but .Net's delegate approach is much better.
MFL is better than YFL.
Admin
I like the Google ads for this thread... :)
Admin
That... was painful.
Admin
The plural of 'knife' is 'knives'.
Admin
That's an insult to C# coders :p
Admin
btw, as it was already said, it in Java, not C#.
At least, this could possibly be easy to fix; just implements those methods in an abstract base class and inherit it where needed...
Admin
Guess this makes Java a WTF-worthy language.[8-)]
Admin
<font face="Georgia">It's possible to produce a WTF in any language. It's not the language, it's the programmer.
<font face="Georgia">This is fairly reasonable: you keep your operations in separate modules and bring them all together in one place. It doesn't matter so much that the Dispatcher is a huge honkin' piece of blather, because at least it's centralised and easy to understand.Until someone mentioned the <event>Listener issue and cast it in a new light (what can I say - I'm not a Java programmer so I don't know this stuff) I would have almost seen the reason for today's WTF. My theory was that the programmer had produced lots of interfaces that each did a single, discrete job, which is a Good Thing TM. Then, he had a single class that pulled it all together, presumably some sort of dispatcher of multiple operations. In the old days you'd do it like this (demonstrating in some made-up language):
</font>
However: today's WTF is not this. It's just a WTF. Can't do anything about it, other than instructing the programmer on the pros and cons of extreme event-handling.
</font>
Admin
Its much more than the latest Spishak product.
It slices, it dices,makes julien fries
Sings, dances and plays the guitar.
Admin
That's weird, it seems to be missing all the system, io, network, shutdown, and ui listeners. Man, what an abject failure. This should listen to EVERY event that could ever possibly occur, and make sure to handle it. If necessary, rewrite Java.
It's bound to come out better anyway.
Admin
Frankly, I don't see this as a WTF. Java Event Listener interfaces generally consist of a single method. If this were in MFC you'd have a message map like so:
BEGIN_MESSAGE_MAP(CMyWnd, CWnd)
ON_MESSAGE(WM_MESSAGE, OnMessage)
ON_MESSAGE(WM_ERROR, OnError)
ON_MESSAGE(WM_HELPREQUEST, OnHelpRequest)
ON_MESSAGE(WM_OPENSCHEDULE, OnOpenSchedule)
ON_MESSAGE(WM_ATTRIBUTEBIGLIST, OnAttributeBigList)
ON_MESSAGE(WM_OKLISTENER, OnOKListener)
ON_MESSAGE(WM_DELETESCHEDULE, OnDeleteSchedule)
ON_MESSAGE(WM_REFRESHSCHEDULELIST, OnRefreshScheduleList)
ON_MESSAGE(WM_SCHEDULEWEEKCHANGE, OnScheduleWeekChange)
ON_MESSAGE(WM_NETWORKCHANGE, OnNetworkChange)
ON_MESSAGE(WM_SCHEDULEITEM, OnScheduleItem)
ON_MESSAGE(WM_LAYOUTCHANGED, OnLayoutChanged)
ON_MESSAGE(WM_ITEM, OnItem)
ON_MESSAGE(WM_INTERNALFRAME, OnInternalFrame)
ON_MESSAGE(WM_RENAMESCHEDULE, OnRenameSchedule)
ON_MESSAGE(WM_CANCEL, OnCancel)
ON_MESSAGE(WM_MIRRORPOLICYCONTROL, OnMirrorPolicyControl)
END_MESSAGE_MAP()
I've certainly seen my share of MFC classes with message maps larger than that. The only WTFs I see are in the names of some of these listeners and in the fact that Java uses interface inheritance for event notifications, neither of which are likely in the control of the person who wrote this code.
Admin
While I would certainly agree that MFC message maps are the ugly beasts on the face of the planet, they actually use a cool little hack to map the actual events that one does indeed wish to handle to a class member function.
Now, I won't pretend to know the intricacies of java, however, if you are implementing an interface, can you provide a partial implementation in java or do you have to implement all of the methods for that interface? If it is the latter, then I would certainly say that the MFC version is less a WTF, yet more WTFugly.
Admin
No, it's a convention, not a requirement.
The entire interface model is by convention, there's not even any language construct to force you to obey any programmatic constructs.
The real WTF is the mess that java forces on you to follow the "Conventional" event model, which till doesn't even handle cross-thread events safely (not that .NET does either. but that's a different story).
Admin
It would be interesting to see the code for this. It could well be that this class has only one method, along the lines of:
This would make a "generic listener" that you could attach at any place in the system to log the events that are being generated.Of course, one would then wonder why it doesn't implement a generic Listener interface of which all of the above are subinterfaces, but maybe the WTF is that the API doesn't have that.
Admin
Actually, I think this is Java because of both the "{...}"s and the "implements" keyword
Admin
exactly my first thought when i saw this piece of code.
tobi
Admin
You can extend the adapter class for that particular interface and override only the methods you need.
Admin
You mean the WTF here wasn't the placement of the { ? [:D]
Admin
If you are criticizing this class declaration you obviously have no understanding of object oriented design.
Admin
It's the vitameatavegamin of programming!
Admin
I work with Java, and this is like the WTF of OO design. I can also never shake the feeling that Java forces you to create WTFs by design...
Admin
I Swiss Army Knife?
Admin
<FONT style="BACKGROUND-COLOR: #efefef">but why leave out 'KitchenSinkListener'?</FONT>
Admin
<FONT size=2> </FONT>
<FONT style="BACKGROUND-COLOR: #efefef">but why leave out 'KitchenSinkListener'?</FONT>
<FONT style="BACKGROUND-COLOR: #efefef" size=1>Because that would be gratuitous?<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>
</FONT>Admin
Note about inheritance - yes VB.NET (and C#.NET, and WHATEVER.NET) support inheritance - but NOT multiple inheritance. So, interfaces would have to be used to fill that void.
Admin
In Java, if you have an interface (not a class), you must provide implementations for every method it names. This is because an interface is a form of a contract; it's a programatic way of stating, "I will always provide you with these methods".
The Java language developers quickly realized that many API users wouldn't want to provide implementations for all the events in a single listener interface. An example: WindowListener, I may only be interested in when the window is closed (so I can cleanup), but don't care when the window is minimzed or maximized.
So they provided classes called Adapters, which provide a default functionality for all the events in a given interface. So, the WindowAdapter class implements the WindowListener interface and does nothing when any of those events are provided. In design-pattern terms, this is an example of a Null Design pattern object: an object that meets a contract (interface) but doesn't actually do anything.
So, now I can make an new class extended from WindowAdapter that extends only the methods I care about and get proper default functionality.
As a few asides: this is all due to the mess that is Java's event conventions. Also, any one with any software-engineering competence quickly realizes that having both WindowListener and WindowAdapter is redundant; you could just have WindowAdapter and let the contract be implict in it's declaration. However, explict contracts seem to be the underlying practice in all Java design, so we end up with the mess we have.
This isn't true; Java, C# and VB.NET all support multiple inhertience. What they do not support is multiple inhertience in C++ style; with a child class inheriting from multiple base classes. They support a child class inheriting from a single parent and multiple interfaces (object that specify only a contract, not an implementation of said contract).The irony of this is that while it simplies the language for the user, it doesn't make the language implementation any easier to the program. AFAIK, Java cannot handle the case where any two parent objects (be they classes or interfaces) declare the same method signature, it will fail to compile.
C++ provides mechanisms around this issue, as does C#.
Admin
Admin
Admin
NB: This forum software is tremendously broken. Somebody should fix it.
Still, I'm impressed by the originality of this quoting Bug.
Admin
Re: "This isn't true; Java, C# and VB.NET all support multiple inhertience. What they do not support is multiple inhertience in C++ style; with a child class inheriting from multiple base classes. They support a child class inheriting from a single parent and multiple interfaces (object that specify only a contract, not an implementation of said contract). "
I think you are saying exactly what I said, just in another way.
Admin
The key part, which you failed to quote, was "So, interfaces would have to be used to fill that void."
Admin
Yes, but it still is multiple inhertience.
People seem to think the interface construct is a magical thing; it's not, it's just a less-expressive (and arguably, less vauge when used correctly) object construct.
Saying Java doesn't have MI is somewhat like saying Java doesn't have pointers. It does, it just doesn't in the C/C++ sense.
Admin
It depends on how you define multiple inheritance.
The definition I subscribe to is "<font>a derived class with multiple base classes."
By this definition, I am correct.
Your definition is more like "</font><font>Inheritance from more than one existing construct".
It's a semantic issue.
</font>
Admin
Whatever do you mean by "less vauge"? Or "used correctly"?
And what's that "object construct" you're talking of? As far as I remember, there are no "interface-objects" - just objects of classes possibly implementing some interface(s). Even anonymus classes implementing some interface are just that, classes.
Yeah, right. But then, talking in the C++ sense, Java lacks references. (Besides some other really useful things.)
Also, my original question, before the board swallowed it last time, concerning the redundancy of WindowAdapter et al: Would you really prefer to be forced to derive from WindowAdapter or whatever Listener you might need to extending a class of your choice? Since, talking C++ of course, Java has no MI!?
I'm no Java guru, so you might care to help me out a little and enlighten me on these few things...
Admin
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.
Remeber that in C# and Java, everything that can be specified in an interface can be specified in an abstract class as well. Note that C++ doesn't have an explict interface construct, but I still can create them.
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.
However in Java, frequently you have to have both because of the way the MI model is designed.
Perhaps an example will make things more clear. Say I have an object that wants two events: one when it succeeds and one when it fails (let's ignore the more obvious choice of a generic completion event with a success/fail flag). I need to handle three posibilities:
So, I have a few options as how to design this:
[code language="Java"]public interface ObjectSucceededListener {
public void objectSucceededListener(ObjectEvent e);
}
public interface ObjectFailedListener {
public void objectFailedListener(ObjectEvent e);
}[/code]This is an OK approach, but has some problems: it means the object generating the events has two keep two lists of events, one for success and one for failure (major); clients of type 3 have to declare themselves as implementing both interfaces (minor) ; and clients of type 3 have to register themselves twice (major). For two events, registering twice in no big deal. For thirty events, it's a PITA. Also, in Java, you'd have to write the same stupid code for each event you want to send, which is tedious and can be error-prone if you have a lot.
So while this is a workable solution, it's far from ideal. Let's see if we can do better.
public abstract void objectSucceeded(ObjectEvent e);
public abstract void objectFailed(ObjectEvent e);
}[/code]This solves the problems for clients of type 3. However, it creates a new problem for clients of type 1 and 2: they must implement some sort of behavior for whichever event they're not interested in. So we've just traded one set of problems for another. We can solve this by doing:[code language="java"]public class ObjectCompletionAdapter extends ObjectCompletionListener {
public void objectSucceeded(ObjectEvent e) { // Do nothing }
public void objectCompleted(ObjectEvent e) { // Do nothing }
}[/code]This solves the problem: now clients of all types can be served by our model, and the sending object only needs one list of events.
However, note the important part: What is the difference between ObjectCompletionListener and ObjectCompletionAdapter? Two blocks of "{ // Do nothing}". That's it. So isn't the ObjectCompletionListener interface redundant? Yes, it is. Which was my point. Everything the interface specifies is already specified by the class that extends from it.
So is the interface useful? If the behavior the class implements can't be used by everyone who wishes to implement the interface, then yes, it is useful. But the reality of it is that an Adapter that does nothing can implemented by anyone who would implement the inteface proper.. So in this case, the interface is redundant, and can be removed. This is ignoring the limitations of Java's MI model that may require you to have the interface anyway in some situations. Normally, you can get around those by creating an inner class or an anonymous class.
Yet, we see this pattern of interface -> class -> everyone else all the time in Java. Interfaces are useful when you want to state a set of behaviors (methods) that can be implemented by disjoint sets of data (meaning the behaviors are independent of the data/object that implements them) and there is no valid default behavior.
It's the last bit, the "no valid default" bit, that people forget.
That being said, the harm is somewhat negligible. It just means you have a redudant specification of your interface, which isn't inherently evil or anything of the sort. But it isn't something you have to do either, and I see people all the time writing code where every public method is specified in an interface even when it's unnecessary.
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.
I was refering specifically to classes and interfaces. In other langauges, anything a class can inherit from would be included.
You can create a variable of an interface type though, and then only have access to the methods the interface stated
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.
So in this case, I don't see the gain. That being said, don't take that to mean I think interfaces should go away: they're a useful construct. And I do prefer having an interface type than having to do the C++:[code language="C++"]class Foo {
public:
virtual void func1() = 0;
virtual void func2() = 0;
};[/code]At the very least, the different in name (interface vs. class) makes my intent clear with what I'm creating. Sure, you can do the same thing with an ABT, but that doesn't make it neccessarily better. But if I do have default behavior that's valid all of the time, then I don't see the point of not creating just a class.
Hopefully I've been clear enough so you can understand what I'm getting at.
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.Especially in C++ (which is where this thinking seems to come from) interfaces are classes (as in, they use the same keyword). Specifically, a pure C++ ABT is equivalent to a C# or Java interface.
</font>