Out on HF and heard nobody, but didn't call CQ? Nobody heard you either. 73 de N7GH
Les Morgan wrote:I go by this general rule of thumb:
--interfaces are building block that can be added together, as you have already stated, so I can build a "tool box" of sorts using interfaces so there will be known ways of accessing things, yet leaving the implementation up to the individual.
--abstract classes are here is what I think, and there you go--deal with it.
Yes, there are similarities in each approach, but the abstract class is more rigid, in that, you cannot add multiple abstract classes together.
himashree rawat wrote:When should i go for an interface and when for an abstract class, other than one reason that interface is flexible as we can implement multiple interface?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Zachary Griggs wrote:Which one you should choose depends on the purpose of the code you're writing. The guideline is that interfaces represent a behavior of an object (not a noun, usually ends in -able), while an abstract class represents a type (a noun)
Zachary Griggs wrote:Which one you should choose depends on the purpose of the code you're writing.
There would be no reason to extend a Comparable, even if you could - it doesn't make any since, since Comparable does not tell you anything about the class that implements it except the one specific thing it was implemented to accomplish.
On the other hand, an abstract class is just like a class, but needs more details before it's ready to be instantiated. Consider an abstract class Person...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:On the flip side, and specifically regarding version 8, I would use default methods sparingly; otherwise you risk your interfaces becoming de facto "implementations", and that is NOT what they were intended for.
Stephan van Hulst wrote:What's wrong with de facto implementations? Can you point out downsides?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Stephan van Hulst wrote:What's wrong with de facto implementations? Can you point out downsides?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:A skeleton implementation (ie, an abstract class) will have been set up specifically to provide one and so, one assumes, will be documented with that in mind.
An interface, OTOH, isn't supposed to have an implementation, so if you start bashing out a whole raft of default methods for it, you not only have to document its behaviour, but its implementation as well.
Don't get me wrong, I like default methods and think they're long overdue; but I don't think of them as an alternative to a skeleton implementation. In fact I can't think of an interface I've ever written where I would want to default more than 2 of its methods (and generally only one).
My worry is though that we will start to see large interfaces written basically as implementations simply because someone wants to use it as a "function"; and that bothers me.
If Java really does want to turn interfaces into de facto implementations, then it should allow the construct 'default final'; and if it does, then I take everything back.
Winston Gutkowski wrote:1. Interface methods are, by definition public, and by allowing people to default them, we may be encouraging bad practise - for example, providing a public implementation for a method that in an abstract class we might have made protected, or even package private; or defining constants in an interface so that a default method can use them.
2. Interfaces will start to be written as "skeleton implementations" to take advantage (?) of multiple inheritance.
Simply put: A default method in an interface behaves like a non-final public method in a class, but you don't write it for the same reasons. My worry is that people will start to.
Stephan van Hulst wrote:While I agree that this makes an interface less 'pure', I don't mind it as much because I'm used to Sun/Oracle's "This implementation" documentation convention.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Brian Goetz wrote:The proximate reason for adding default methods to interfaces was to support interface evolution, but we were well aware that we were going beyond that. Whether you consider that to be "interface evolution++" or "traits--" is a matter of personal interpretation. So, to answer your question about safety ... so long as you stick to what the mechanism actually supports, rather than trying to wishfully stretch it to something it does not support, you should be fine.
A key design goal was that, from the perspective of the client of an interface, default methods should be indistinguishable from "regular" interface methods. The default-ness of a method, therefore, is only interesting to the designer and implementor of the interface.
Here are some use cases that are well within the design goals:
Interface evolution. Here, we are adding a new method to an existing interface, which has a sensible default implementation in terms of existing methods on that interface. An example would be adding the forEach method to Collection, where the default implementation is written in terms of the iterator() method. "Optional" methods. Here, the designer of an interface is saying "Implementors need not implement this method if they are willing to live with the limitations in functionality that entails". For example, Iterator.remove was given a default which throws UnsupportedOperationException; since the vast majority of implementations of Iterator have this behavior anyway, the default makes this method essentially optional. (If the behavior from AbstractCollection were expressed as defaults on Collection, we might do the same for the mutative methods.) Convenience methods. These are methods that are strictly for convenience, again generally implemented in terms of non-default methods on the class. The logger() method in your first example is a reasonable illustration of this. Combinators. These are compositional methods that instantiate new instances of the interface based on the current instance. For example, the methods Predicate.and() or Comparator.thenComparing() are examples of combinators.
If you provide a default implementation, you should also provide some specification for the default (in the JDK, we use the @implSpec javadoc tag for this) to aid implementors in understanding whether they want to override the method or not. Some defaults, like convenience methods and combinators, are almost never overridden; others, like optional methods, are often overridden. You need to provide enough specification (not just documentation) about what the default promises to do, so the implementor can make a sensible decision about whether they need to override it.
Junilu Lacar wrote:NOTE: see also this related topic
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here