- 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
fristt!!
Admin
It's not even self-documenting. A name that's a sarcastic and mis-spelled editorial commentary on the class does not explain the most important part of this interface: why does it exist? What is it for?
Admin
The problem is obvious: they didn't prefix the interface name with "I"! Had they done it, they would've been in a much better spot.
Or not...
Admin
Looks like something that was renamed by the previous guy who tried to refactor...
Admin
Some really, really doesn't like interfaces.
Admin
Oh yeah i know a lot about this thing
Admin
I know a lot about this thing for sure
Admin
Interfaces have one use and one use only. And that's to act like the equivalent of C++ header files when distributing your code.
Sadly bad choices on part of language designers have lead to them being pushed to become a substitute for classes in the inheritance structure. And that leads to idiocies like these.
Admin
Ooh, I don't know that I'd agree with that. Using interfaces to swap out implementations at runtime is incredibly useful. Specifying dependencies in the form of contracts is much better than specifying based on concrete types, and also better than specifying based on abstract classes. Yes, we should minimize dependencies, but at the end of the day, you will write classes that depend on other classes, and specifying that relationship based on
can doinstead ofis aworks a lot better for building easy to modify code.Admin
It might be "not that very usefull" but it does seem to be "brillant"!
Admin
Which is exactly the use case I described.
If your code is distributed over several modules that are entirely separate entities but need to integrate with one another than you need some sort of equivalent to C++ header files so that one can include the other without having to worry about implementation details. And that is what interfaces are for.
Where I take issue with them is when they get taken out of this niche and into the wider world of inheritance where they become a poor mans replacement for multiple inheritance or worse an unnecessary promise in a system which is neither distributed nor modular in nature.
Admin
Ah, that better illustrates what you meant about "like C++ header files". That makes sense.
Admin
Well, for IoC interfaces are super useful. Also for testing (specifically mocking and substitution).
For meta information obviously should use annotation. Issue tho is that while they are a core concept of for example the .net language family, Java was way, way behind the curve - which is a horror for such a core language feature. And then Java developer did, what they do best, abuse interfaces for meta markers. So yeah, in Java projects you will find tons of those still because obviously nobody refactors code ever in a professional environment; that only happens in hobby projects where quality actually matters :-)
Admin
I can see this as an alternative to applying @Deprecated to a class. Creating an annotation @NotVeryUseful would of course be preferred, but I am not convinced this is a WTF.
@LZ79LRU, this type of usage doesn't fit the 'C' header pattern. We should not use instanceof, but it is still part of the Java language.
Admin
There is one useful thing that an empty interface like this can do - it can be a "marker" interface, so elsewhere in the code you can do
if (x is NotThatUsefull) { ... }Whether or not this is the best way to achieve whatever needs be achieving is a different question, but at least there's some sense behind it.Addendum 2023-04-12 15:40: That said, I'm too old and cynical to believe that this was the case here.
Admin
It's obviously for security, so that certain parts will only work with classes from its own library. If you try to inject your own classes in there, they won't work, because they won't derive from this inane interface. Yep, that's how you do that.
Admin
It's obviously for security, so that certain parts will only work with classes from its own library. If you try to inject your own classes in there, they won't work, because they won't derive from this inane interface. Yep, that's how you do that.
Admin
Sometimes I wonder if I could pass one of these "WTF design patterns" past our internal code review process. This one I'm positive I could, given a carefully selected code review, by sneaking the change as part of a larger refactoring.
Admin
Not that usefull when every class in the program inherits it.
Admin
They are useful for testing, yes. That's another application of the modularity I spoke off.
At this point I think it would be best to explain my thesis about interfaces.
You see, it is my view that interfaces are a useful tool. But by their nature they are also a cost center. Whether you are using an IDE or not they add complexity to the creation, understanding, modification and maintenance of your system by adding additional hoops to jump through both physically and mentally for all of those operations.
And whilst this cost might seem trivial on a per class per access basis when looked at from a distance, it most certainly is not. Because it is always one extra thing that you need to think about and keep track off. And in sufficiently complex systems that added mental work load adds up remarkably quickly.
And when you combine that with the fact people often misuse them for metadata information as you said or as a bad crutch to alleviate the lack of multiple inheritance you get the code equivalent of red tape. Pointless code-paperwork that adds nothing of value and just slows everything down and makes even simple operations far more complicated than they need to be. Doubly so if the reason you are forced to use them is because of a top down architectural decision done by your boss or an external library.
Bottom line, what I am saying is that interfaces are a useful tool if used for the thing they were meant to be used for. Which is as promises of "interface" for the purposes of modularity and interoperability, be that with your own code or someone else's. But that's it.
They are not useful for any other purpose. And the cost they incur is real. Thus they should only be used if and when needed and not just sprinkled around your codebase preemptively because someone read a single book in his life and now thinks he is the second coming of Dijkstra and needs to be able to mock the Integer class just in case Microsoft decides to change it in the future.
Admin
Or, to put it another way. Interfaces have a use. But more often than not when people speak of the glory of interfaces and how their system is going to use them to their full potential, especially in Java it brings to mind a great band playing one of their best songs...
Make a joke and I will sigh And you will laugh and I will cry
Admin
My personal problem with interfaces is that I'm working in a codebase where about 60% of the logic is stuck in ThingService which implements IThingService, and ThingService is the only implementation. All other classes consume an IThingService via Ninject. So when I look at a method or property of whatever's using IThingService, and I hit F12 in Visual Studio, I'm always taken to the interface, not the implementation. And I'm only interested in the interface maybe 2% of the time. (And then I go back and hit Ctrl-F12, so at least it doesn't stop me for long.)
Thankfully, the newer code we're writing just has StuffService that doesn't implement anything at all, so F12 takes me to the implementation.
(As a side note: this code doesn't have enough tests. But that's a different issue.)