Talk:Constant interface

Arbiter of anti-patterns?

Who decides what is and isn't an anti-pattern? I ask this because I, for one, disagree with the notion that Constant Interface is necessarily a bad idea. What's bad is not merely defining constants in an interface, but the overlap of interface and implementation. I know that the original purpose of the Java Interface was to be an interface, but it just so happens that they also make good constant packages. Often in my programming I will make some interfaces that are actual interfaces, and others that are constant collections. I never conflate the two. I think the real anti-pattern here would be in mixing them both in the same Java Interface.

—Preceding unsigned comment added by Mbarbier (talk • contribs) 14:13, 20 May 2009

It is an example of an anti-pattern because it removes the context of the constant. Much like enumeration values, constants are only so useful, they cannot be used meaningfully out side the scope they were intended. This has several negative effects:

Without an IDE that works out the where the constant is coming from, the user is left to dig through all of the interfaces.
It pollutes the object with constants that are not unique to it.

But to answer your first question, Sun, the creators of Java have classified it as an anti-pattern, see: static import. -- BlindWanderer (talk) 07:11, 30 May 2009 (UTC)[reply]

You're wrong about the classification, BlindWanderer. Only person who explicitly *said* that this is an antipattern and why is Bloch himself - and he stated some dubious and discussable things in his EJ,2nd... Oracle only cites him, not providing any rationale nor explanation.

Static import also removes the context. But I agree with the pollution; exactly why you should keep static imports sections and constant interfaces as small as possible.

On the other hand, Java's very own internals (e.g. Swing source code) uses interface for constants. Added a note on page. I'm 100% with Mbarbier on this.

Vaxquis (talk) 23:46, 13 May 2013 (UTC)[reply]

Arbiter 2

As user "Immerhin" used *three* consecutive edits to first edit and then remove the content provided by me, then vandalized my user talk page with flame comment, and because his opinion on the matter in hand (Constant interface) was neither cited nor sourced nor had he provided a rationale for his edits, I'm reverting the article to its previous form.

To all whom it may concern: I did my homework a long time ago and read both Bloch's and other influential people's opinions on Java. Bloch considers Constant interface an antipattern - but he also e.g. produced a lot of ineffective code in Collections (I've posted improvements to his code to OpenJDK a couple of times); his views on OOP sometimes differ a lot from what other OOP scientists consider optimal and, from a point of passing time, he changed or distilled his views on many matters. I'm not trying to discredit him, just point out that, while his arguments are usually quite strong and sensible, he isn't and won't be any kind of God-like figure, as he's just simply a designer and developer. Same applies to JLS and other sources; constant interface is an interface design considered by some sources to be bad or suboptimal, that's all. Saying something IS bad is in no way better nor more encyclopedic that saying that *somebody* (and pointing out who) CONSIDERS it bad. That's exactly the kind of difference hidden in phrase "Go To statement considered harmful". Both constant interfaces and gotos have their uses, and while they are usually signalling some deficiencies in the code, they may also simplify it and make it more concise if used carefully. That's exactly why I edited the article in the first place. As long as Java libraries use constant interfaces themselves, I think that saying "burn all constant interfaces with fire, they are so evil" is an overstatement. I agree with 98% of the article, edited the 2% I consider not straightly true. That's my 5c on the matter. Not trying to fight a war here.

To Immerhin: just because you disagree with something doesn't mean you're right - and, even if you're possibly right, unless you can provide sources backing you up, your opinion doesn't matter; because it's just that - an opinion. Science isn't about opinions, it's about facts. Non-neutral POV is NOT accepted on Wikipedia. Calling something 'nonsense' won't make it less sensible; either use hard proof (cites/links/sources) or keep your opinion for yourself. Further reading: Scientific method

PS. just browsed through Immerhin's alt user pages (http://wiki.riteme.site/wiki/User:Immerhin, http://wiki.riteme.site/wiki/User:Broadside_Perceptor, http://wiki.riteme.site/wiki/User_talk:Belchman) and realised he had already been warned/banned multiple times. *sigh* Could've just reverted the edits and notified the admins instead of writing this all... Vaxquis (talk) 21:40, 31 May 2013 (UTC)[reply]

It is judgmental

I agree with the previous author; this is not so much an antipattern, but just an awkward solution on some occasions, and pretty good on others. Mixins bring in functions and values "outside of context", and they are pretty good in mixing together the right contexts, e.g. in cake pattern. In Scala and in Python traits may contain implementations, if used in mixins; there's nothing wrong in it, except maybe looking unfamiliar to the people who only know Java. Josh Bloch does not like constants in traits; okay, nobody forces him to use them. But we do, in Scala, and we will. Especially because a function is a value in Scala, and so is a constant - a function defined on Unit.

I suggest to remove this article. Vlad Patryshev (talk) 22:03, 2 September 2014 (UTC)[reply]

Outdated and dangerous

The author Bloch uses with vastly outdated arguments like "What if you don't have an IDE?" or silly ones like "What if someone accidentally implements that interface in a class?"

Now one side to this problem is that this is outdated/invalid information in an encyclopedia, the other issue is that a lot of people quote Wikipedia to support their view on the matter. In effect the clearly better technical solution is not implemented, because of outdated/invalid information on Wikipedia, and that is an actual problem.

TwoThe (talk) 13:14, 11 December 2020 (UTC)[reply]

Effective Java 3rd Edition

Item 22 - Use interfaces only to define types

When a class implements an interface, the interface serves as a type that can be used to refer to instances of the class. That a class implements an interface should therefore say something about what a client can do with instances of the class. It is inappropriate to define an interface for any other purpose.

...

The constant interface pattern is a poor use of interfaces. (...) Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility.

...

There are several constant interfaces in the Java platform libraries, such as java.io.ObjectStreamConstants. These interfaces should be regarded as anomalies and should not be emulated.

...

In summary, interfaces should be used only to define types. They should not be used merely to export constants.

There is no mention in the chapter to accidental implementation or not having an IDE. — Preceding unsigned comment added by 62.218.164.126 (talk) 15:34, 14 January 2021 (UTC)[reply]