This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Alternative of Multiple inheritance in Java
Multiple inheritance in Java?
i have a code like so:
public class myApplet extends JApplet
im interested in adding another extend like so:
public class myApplet extends JApplet, extends Object implements Serializable
can this be done some way and how?
Java doesn't have multiple inheritance, and any class extends Object anyway, so it's useless in that case.
you can not extend more than one class in Java. But you may implement more than one interfaces.
However, if your parent is a child from another parent you are of course also extending all classes in the hierarchy.
If you do not add a extend-statement, Object is automatically choosen as parent. Object is the super-parent, and in every hierarchy you will find it. Therefore in your case you can skip the "extends Object" as the hirachy is the following:
java.lang.Object
extended by java.awt.Component
extended by java.awt.Container
extended by java.awt.Panel
extended by java.applet.Applet
extended by javax.swing.JApplet
extended by your.package.myApplet
(see http://docs.oracle.com/javase/6/docs/api/javax/swing/JApplet.html)
Java doesn't have multiple inheritance, but you can implement multiple interfaces.
public class myApplet extends JApplet implements Serializable, SomeThingElse
You don't need to extend Object since all classes will extend it.
If you're in the situation where you have methods in two classes you'd like to share in a single class, consider defining a third class which uses these two classes if the functions sets are cohesive and perform different operations. Don't try to combine classes to gain their powers. Create separate classes which tackle different problems and store instances of these in higher order classes.
If you do have two classes which perform similar functionality, it may be possible to abstract their common code into a superclass. So Class A would extend Class B, and you would in turn extend class C and add more specifics there.
If you have two classes which are very similar in structure but operate on different data structures or algorithms, then you might consider creating an interface which they both implement. A good example of this is a Vehicle interface which has a drive() method. A Car will have a different implementation to drive() than a Motorbike.
To extend this last idea, if these classes will share common code and it's possible to say "A Car is a Vehicle" and "A Motorbike is a Vehicle", then it's likely that using inheritance is preferred to an interface, with Car and Motorbike both extending Vehicle and it's abstracted functions.
You can't extend class twice in java... Nevertheless every class in java inherits from class Object instantly, so you don't have to extend your class with Object class ;)
No, Java doesn't support multiple inheritance. Every class inherits from Object automatically though.
Java doesn't support multiple inheritance,you can use multiple interface
Related
This question already has answers here:
When to use an interface instead of an abstract class and vice versa?
(26 answers)
Abstract class vs Interface in Java
(15 answers)
Closed 8 years ago.
I understand the technical difference between the two, but I don't understand why one is better to use than the others? Can anyone give me an example that would help me distinguish an advantage one has over the other?
For example: If I was making an rpg game, and I was working on some healing items. What would the uml diagram look like. Would I be using an interface for items, and then healing items or abstract classes.
When to use interfaces
Interfaces are basically used to inherit the behaviour, as we know interfaces can only have abstract methods. When a class implements that interfaces it has to implement all its abstract methods (unless the class itself is an Abstract class), thus it behaves according to the way interfaces defines.
For example, if you want your class to behave as a Thread. You need to implement Runnable interface and override its run() method.
We need to inherit behaviour of two or more forms.
Interfaces are basically created when we know what to do, but we don't know how to do it. To explain in simpler terms I would say, suppose there are 5 tasks which you know must be done. But there can be different ways to do them. Any class implementing them can do them in any way they wish to. So create an interface and put your methods in them.
When to use Abstract class
We know abstract classes can have both abstract as well as concrete methods.
So same example, if you have 5 tasks to be done but for one task there is one default way to do, so you will wish to define its body and you won't be able to do so in interfaces.
In this case we'll create an abstract class. Put 4 abstract methods and one concrete method, which will be inherited by its child classes directly and they won't need to define it on their own. However if they wish they can override its functionality.
Also keep in mind, a class can extend only one abstract class at a time.
This question already has answers here:
Why an interface can not implement another interface?
(7 answers)
Closed 9 years ago.
EDIT: The simple answer to my question is that Java allows one interface to extend multiple other interfaces. This is what answers my logical question of how you group interfaces together in a common interface. This answer did not appear in the dupe question. Also the question was different, it was not about creating interface groups.
Is there a reason in Java you cannot define one interface as implementing other interfaces? The answer I've seen and been dissatisfied with is that "interfaces themselves don't contain implementation, so how could an interface implement other other interfaces?" Well, that's a weak answer in my opinion, because its more a nod to English semantics than it is logical interpretation of the scenario. The logical interpretation of the scenario is since we can define classes to implement many interfaces, why can't we define an interface that itself represents a collection of interfaces.
Suppose you have many classes that you want to each implement a large, common set of many interfaces. As it currently stands, you'd have to explicitly write out the list for each class. This means that if later you had to add another interface to your list of many, you'd have to modify each class. Having all the interfaces consolidated in one "super interface" would allow the programmer to make the change in only one place.
And before you answer "make an abstract superclass that implements the list of interfaces, and have all your subclasses extend that superclass", keep in mind you cannot assume these classes do not already extend classes. One of the whole benefits of the implements keyword is so that you can adapt a class without having to change its taxonomy, right?
I guess the long story short is: Why can't programmers define interfaces that are just groups of other interfaces? Or, maybe the better question is: If I can't define an interface as implementing other interfaces, HOW can I define interfaces that are groups of other interfaces?
For those of you that prefer code, what I'm asking is why instead of doing this...
public class Foo extends ParentClass1 implements IBar1, IBar2, IBar3{
}
public class Baz extends ParentClass2 implements IBar1, IBar2, IBar3{
}
...wouldn't it make more sense for Java to allow this:
public interface IAllBar implements IBar1, IBar2, IBar3{
}
public class Foo extends ParentClass1 implements IAllBar{
}
public class Baz extends ParentClass2 implements IAllBar{
}
That way, later, if I create IBar4 I only have to modify IAllBar.java instead of Foo.java AND Baz.java.
Edit: So according to below answers I can define IAllBar to EXTEND all those interfaces and I'll get exactly what I want. I'm glad some people are willing to read an entire post before jumping to the bottom to post mean responses.
You can define an interface that's a collection of other interfaces. Its called extending an interface. You can extend multiple interfaces.
As for why you can't define methods in an interface, it's how Java interfaces were defined. And the problem you speak of are the consequences of single inheritance.
However you will be pleased to know that in the new upcoming Java 8 there's an feature called Virtual Extension Methods which addresses the large code base problems you speak of.
Personally I think it's useful in legacy code bases for quick refactoring, but if the system is well designed you should be able to get rid of the default implementations later. And overusing this feature will only result in all the disadvantages of multiple inheritance.
Interfaces cannot be instantiated—they can only be implemented by classes or extended by other interfaces.
I believe what you should do is extend interfaces.
You could do this as shown below:
public interface ManBearPig implements Man, Bear, Pig {
//interface body
}
You could then implement ManBearPig where you need it.
The thing you need to keep in mind is that interfaces support multiple inheritance.
To understand this consider the idea that interfaces Man, Bear, and Pig might each have the method walk() included within them.
If you were to implement ManBearPig in a class and call the walk() method it would implement the walk method of Man, Bear, and pig simultaneously.
According to my understanding, your problem statement is:
How to design a Type hierarchy where a group of Classes implement same set of Interfaces and a number of behaviors exposed by the interfaces have common implementation.
This kind of design problem can be solved in Java in the following way (explaining by your example code)
public abstract class AbstractAllBar implements IBar1, IBar2, IBar3{
/* Provide implementations of methods whose behavior remains unchanges for all of it's children classes.*/
}
Now this abstract class can be extended by the classes who have common set of behaviors as defined by the abstract class AbstractAllBar.
public class ParentClass1 extends AbstractAllBar {
.......
}
public class ParentClass2 extends AbstractAllBar {
.......
}
public class Foo extends ParentClass1 {
}
public class Baz extends ParentClass2 {
}
This kind of abstract classes provide Skeleton Implementation. Examples of Skeleton Implementation can be found in Collection API. You can refer source code of AbstractList and AbstractSet to make it more clear.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
When to use abstract class or interface?
I am a newbie in Java , can anyone please explain a scenario where abstract class will be
useful and interface will not be and vice versa.
I believe in not so complex problems both can solve the issue with equal ease.
Please explain in layman's term and pardon my ignorance!
When we create an interface, we are basically creating a set of methods without any implementation that must be overridden by the implemented classes. The advantage is that it provides a way for a class to be a part of two classes: one from inheritance hierarchy and one from the interface.
When we create an abstract class, we are creating a base class that might have one or more completed methods but at least one or more methods are left uncompleted and declared abstract. If all the methods of an abstract class are uncompleted then it is same as an interface. The purpose of an abstract class is to provide a base class definition for how a set of derived classes will work and then allow the programmers to fill the implementation in the derived classes.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Abstract class and Interface class?
When i need to use abstract class and interface in Java?
My doubt is
Which situation i need to use abstract class and which situation i need to use interface.
interface satisfy the abstract class properties. so then why we need especially abstract class?
i know, that abstract class contains abstract methods and non abstract methods, but we can use abstract class as a ordinary class, then the result will be same in the both classes. the ordinary class also inherited same as abstract class. So why we need abstract class.
If anybody know the good example please reply me.
Thanks.
Another important aspect of abstract class is that unlike interface, adding new methods to it won't break binary compatibility. So, from the API evolution point of view, especially when you can expect additions to the public API, abstract classes are more preferable.
I would say that there are two types of inheritance. One I would say as Implementation Inheritance and other as Contract Inheritance.
Abstract classes are used for having Implementation Inheritance. You can extend/change the behavior of your super/parent class.
Interfaces would go for Contract Inheritance. Where you are more interested in having the class implement some kind of a contract (service methods with arguments - more of a contract) and the behavior is different for different implementation, nothing generic that you can bundle up in an abstract class and extend the behavior.
You need to use abstract classes if you want to apply the template pattern http://en.wikipedia.org/wiki/Template_method_pattern, usually in framework code. As a rule of thumb, if you're not intending to implement the template pattern, you're better off with interfaces, which permit loose coupling, the way spring framework does. Loose coupling leads to a design open to evolutions and a better testability, with techniques like mock objects (http://easymock.org)
This question already has answers here:
When to use an interface instead of an abstract class and vice versa?
(26 answers)
Closed 8 years ago.
Can anyone tell me what exactly the difference between an completely abstract class and an interface?
An Abstract class can also have all its methods as abstract. An interface has all its methods as abstract. What is the main difference between the two in this scenario?
If there is difference between a pure abstract Class and interface? What is the use of interface? Where interface is being used we can make use of pure abstract class?
To complete the former answers :
An interface is a "contract". If a class implements an interface it have to propose all the services listed in the interface.
An abstract class is a skeleton. It defines a certain way its extended classes will work while letting them some free space (the abstract methods) to be unique.
A pure abstract class doing the same thing as a interface but have the problem of unique extending so, for me, it have no interest
Every interface is implicitly abstract: Every method declaration in the body of interface is implicitly abstract and public.
An abstract class has methods that can contain implementation. Abstract methods can be either public, protected or default access (package visible). Unlike interfaces abstract classes can contain fields that are not static and final.
Also see:
Interfaces vs Abstract classes and the
Java tutorial
In Java and C#, one can use multiple interfaces to derive from and only a single class to inherit from,
One reason to choose pure abstract over interface is to force sub classes to implement particular methods that are implemented by a super class.
For example (in Java),
Say you want all extending classes to implement toString(), equals(), and hashCode().
You could create an interface called ForceSomeMethods for that contract, but those methods are implicitly implemented by Object.
Making ForceSomeMethods a pure abstract class with toString(), etc as abstract methods, all subclasses will be forced to implement those methods.
It's not a very theorotical explaination but, programatically it's all correct
Interface Abstract Class
Extend Class No Yes
Extend Abstract Class No Yes
Implement Interface Yes(Extend Interface) Yes
Variables Public Static Final Public/Protected/Private/static/final/transient/volatile
Contain Non-Public Method No Public/Protected/*Private
Contain Abstract Method Yes Yes
Contain No-Body, Non-Abstract Method Yes No
Contain Defined Method No Yes
Contain Main Method No Yes
*Abstract classes can have private methods, but not abstract private methods.
An abstract class can provide an implementation, i.e. (public, protected, private) method bodies. An interface can just declare public method signatures. These methods have to be realized (in the form of method bodies) by classes implementing the interface.
There are three differences:
Interfaces can only declare public methods (i.e. no protected or package-private visible methods) and can not declare any fields
Subclasses can only extend at most one abstract class, but can implement any number of interfaces
The abstract class can also have implementations for some or all of the methods
I'm just going to address one point (mainly because the other questions have been addressed already):
"Where interface is being used we can
make use of pure abstract class?"
In theory, you could. However, you will lose flexibility and loose coupling to some extent. It's far more preferable to code to interfaces and pass those around, especially in Inversion of Control (IoC) scenarios and from an integration point of view, as this allows far greater extensibility.
Since the question is about pure abstract classes then I'd say the answer is going to be related to inheritance and scope. It's something I've wondered myself many times and this is what I've come up with.
Obviously the features related to multiple inheritance have been answered previously so I won't go in to any of that. Scope is a big one though.
In an interface you can't define a member's access modifiers since they are implicitly public,...you are defining the public interface for it's eventual implementation. There's an important difference there since you can define a protected abstract member in a pure abstract class.
Inheriting from such a class definition would force the inheritor to implement the abstract member but scope it privately to consumers of the class (though it would have to be defined as protected so unless the class was marked as sealed further inheritors would have access).
In essence you can define a private interface using pure abstract classes. Whether that's a good idea is a different question altogether but one good use I've seen it used for is to enforce design patterns and standardize class designs.
HTH
You can use Interface for multiple inheritance, but you can't use abstract class for multiple inheritance.
All the methods in Interface is public by default, by in abstract class, only the methods which you've set as an abstract need to be declared public.
A class can implement multiple interfaces, but only extend from one class (abstract or otherwise). If you need to specify an interface, then you should use an interface, so that classes may implement multiple of your interfaces.