Suppose I have class hierarchy like the one shown in picture. Suppose I need to include a method doThis() that would have different implementation in classes C and D. But the class B need not implement this method.
Should I declare the contract in Class A and provide an empty implementation in class B or have another abstract class X which extends A and is being extended by C and D?
Thanks
Do not put it into class A. Use an interface that is implemented by those that need it.
If only sub-classes of A will use the method:
Make another abstract class that extend A and adds the method.
If you intend to have that method implemented in different class types:
Make an interface that declares the method, and then C,D should implement that interface as well.
Make an interface called "doable". let your classes C and D implement this.
public interface Doable {
public void doThis();
}
public class D implements Doable { /*implementations*/ }
public class C implements Doable { /*implementations*/ }
Do not put it in A if you can avoid it.
The best solution can not be determined from the information you have given us. It depends on the context and meaning of the classes and methods.
Related
Say I have an interface A and a class B that implements it.
Now, I also have some class C which extends class D (which means that it can't also extends B) but I also need there the functionality of interface A.
The solution I know is to have a member of A instantiated by B in C (which will implement A) and when implementing the functions of A call the matching function from the member of A.
Is there any way to create some connection between the functions of A and the member inside C? (so that java will know that every time it needs to call a function from A it will directly go and and run the matching function from the A member without me needing to write the code for it for every function of A)
A big thank you is waiting to each one of the helpers...
No. As already stated delegation must be implemented manually.
Having said that, you have a few options to simplify this: If you're working with Eclipse, select Source|Generate Delegate Methods... and select your member variable. Eclipse will then generate all the delegate methods for you. I don't know about other IDEs, but I would be surprised, if NetBeans et al. would not have a similar feature.
Another option, if you actually want to decorate existing collection classes, consider Google Guava's Google Guava's Collection Helpers.
Last, but not least, you could consider restructing your code and decorate your classes using Advices. Advices stem from Aspect Oriented Programming (AOP) and typically use a proxying mechanism to enrich original target classes. This is a rather advanced technique, but if you are determined to go down this road, have a look at Spring's AOP support.
So to sum up, here is your class hierarchies:
package common;
public interface A
{
void doStuff();
}
package commom.impl;
public class B implements A
{
void doStuff() {}
}
package real.service;
public class D
{
void doSomeRealStuff() {}
}
package real.service;
public class C extends D
{
void doSomeRealStuffForGood() {}
}
Assuming that each class is declared in its own source file.
Just to recall from the OP, I assume you need B stuff in C and not really A stuff. Because A is nothing but a contract and you need then the real implemting class to be fetched inside your C class in order to call the declared methods on.
In such a case, you may need to use the Inversion of Responsability approach, so that you declare an instacne of type B inside your C clas then you layer each method from B with a one having the same signature and that do nothing but delegate the real call to the instance member:
package real.service;
import common.A;
import common.impl.B;
public class C extends D
{
private A delegate;
public C ()
{
delegate = new B();
}
void doStuff() {
delegate.doStuff(); // Call the real delegate method when doStuff is called on an isntance of C.
}
void doSomeRealStuffForGood() {}
}
Note that this is a legal OO concept, since you are following an HAS-a even though some could consider it a high coupling.
Otherwise if you are not tied to the B class, and you may drop the declare methods in there for some others, you can declare an inner class that implements the A interface the way you need.
Edit:
Java does not support multiple inheritance, though you have provided a common contract in your A interface, so if you need all those methods (behavior) to be availble in your C class, it would be better to implement it directely and override all the interface methods.
I know that a class can implement more than one interface, but is it possible to extend more than one class? For example I want my class to extend both TransformGroup and a class I created. Is this possible in Java? Both statements class X extends TransformGroup extends Y and class X extends TransformGroup, Y receive an error. And if it is not possible, why? TransformGroup extends Group but I guess it also extends Node since it inherits fields from Node and it can be passed where a Node object is required. Also, like all classes in Java, they extend Object class. So why wouldn't it be possible to extend with more than one class?
TransformGroup inheritance
So, if that is possible, what is the proper way to do it? And if not, why and how should I solve the problem?
In Java multiple inheritance is not permitted. It was excluded from the language as a design decision, primarily to avoid circular dependencies.
Scenario1: As you have learned the following is not possible in Java:
public class Dog extends Animal, Canine{
}
Scenario 2: However the following is possible:
public class Canine extends Animal{
}
public class Dog extends Canine{
}
The difference in these two approaches is that in the second approach there is a clearly defined parent or super class, while in the first approach the super class is ambiguous.
Consider if both Animal and Canine had a method drink(). Under the first scenario which parent method would be called if we called Dog.drink()? Under the second scenario, we know calling Dog.drink() would call the Canine classes drink method as long as Dog had not overridden it.
No it is not possible in java (Maybe in java 8 it will be avilable). Except the case when you extend in a tree.
For example:
class A
class B extends A
class C extends B
In Java multiple inheritance is not permitted for implementations (classes) only for interfaces:
interface A extends B, C
E.g. MouseInputListener extends MouseListener and MouseMotionListener
And, of course, a class can implement several interfaces:
class X implements A, F
Multiple inheritance is not possible with class, you can achieve it with the help of interface but not with class. It is by design of java language. Look a comment by James gosling.
by James Gosling in February 1995 gives an idea on why multiple
inheritance is not supported in Java.
JAVA omits many rarely used, poorly understood, confusing features of
C++ that in our experience bring more grief than beneļ¬t. This
primarily consists of operator overloading (although it does have
method overloading), multiple inheritance, and extensive automatic
coercions.
There is no concept of multiple inheritance in Java. Only multiple interfaces can be implemented.
Assume B and C are overriding inherited method and their own implementation. Now D inherits both B & C using multiple inheritance. D should inherit the overridden method.The Question is which overridden method will be used? Will it be from B or C? Here we have an ambiguity. To exclude such situation multiple inheritance was not used in Java.
Java didn't provide multiple inheritance.
When you say A extends B then it means that A extends B and B extends Object.
It doesn't mean A extends B, Object.
class A extends Object
class B extends A
java can not support multiple inheritence.but u can do this in this way
class X
{
}
class Y extends X
{
}
class Z extends Y{
}
Most of the answers given seem to assume that all the classes we are looking to inherit from are defined by us.
But what if one of the classes is not defined by us, i.e. we cannot change what one of those classes inherits from and therefore cannot make use of the accepted answer, what happens then?
Well the answer depends on if we have at least one of the classes having been defined by us. i.e. there exists a class A among the list of classes we would like to inherit from, where A is created by us.
In addition to the already accepted answer, I propose 3 more instances of this multiple inheritance problem and possible solutions to each.
Inheritance type 1
Ok say you want a class C to extend classes, A and B, where B is a class defined somewhere else, but A is defined by us. What we can do with this is to turn A into an interface then, class C can implement A while extending B.
class A {}
class B {} // Some external class
class C {}
Turns into
interface A {}
class AImpl implements A {}
class B {} // Some external class
class C extends B implements A
Inheritance type 2
Now say you have more than two classes to inherit from, well the same idea still holds - all but one of the classes has to be defined by us. So say we want class A to inherit from the following classes, B, C, ... X where X is a class which is external to us, i.e. defined somewhere else. We apply the same idea of turning all the other classes but the last into an interface then we can have:
interface B {}
class BImpl implements B {}
interface C {}
class CImpl implements C {}
...
class X {}
class A extends X implements B, C, ...
Inheritance type 3
Finally, there is also the case where you have just a bunch of classes to inherit from, but none of them are defined by you. This is a bit trickier, but it is doable by making use of delegation. Delegation allows a class A to pretend to be some other class B but any calls on A to some public method defined in B, actually delegates that call to an object of type B and the result is returned. This makes class A what I would call a Fat class
How does this help?
Well it's simple. You create an interface which specifies the public methods within the external classes which you would like to make use of, as well as methods within the new class you are creating, then you have your new class implement that interface. That may have sounded confusing, so let me explain better.
Initially we have the following external classes B, C, D, ..., X, and we want our new class A to inherit from all those classes.
class B {
public void foo() {}
}
class C {
public void bar() {}
}
class D {
public void fooFoo() {}
}
...
class X {
public String fooBar() {}
}
Next we create an interface A which exposes the public methods that were previously in class A as well as the public methods from the above classes
interface A {
void doSomething(); // previously defined in A
String fooBar(); // from class X
void fooFoo(); // from class D
void bar(); // from class C
void foo(); // from class B
}
Finally, we create a class AImpl which implements the interface A.
class AImpl implements A {
// It needs instances of the other classes, so those should be
// part of the constructor
public AImpl(B b, C c, D d, X x) {}
... // define the methods within the interface
}
And there you have it! This is sort of pseudo-inheritance because an object of type A is not a strict descendant of any of the external classes we started with but rather exposes an interface which defines the same methods as in those classes.
You might ask, why we didn't just create a class that defines the methods we would like to make use of, rather than defining an interface. i.e. why didn't we just have a class A which contains the public methods from the classes we would like to inherit from? This is done in order to reduce coupling. We don't want to have classes that use A to have to depend too much on class A (because classes tend to change a lot), but rather to rely on the promise given within the interface A.
Java does not allow extending multiple classes.
Let's assume C class is extending A and B classes. Then if suppose A and B classes have method with same name(Ex: method1()). Consider the code:
C obj1 = new C();
obj1.method1(); - here JVM will not understand to which method it need to access. Because both A and B classes have this method. So we are putting JVM in dilemma, so that is the reason why multiple inheritance is removed from Java. And as said implementing multiple classes will resolve this issue.
Hope this has helped.
Hello please note like real work.
Children can not have two mother
So in java, subclass can not have two parent class.
I'm working on an assignment where I'm trying to implement a class that extends an abstract super class, but by using
public class B extends A{}
However, that gives me the error that type B must implement the abstract method A.act, is there another way in which I can do this without using extends?
Using:
public abstract class B extends A{}
Gives me a different error on another part of the assignment that should be correct.
What should I do? Thanks for the help.
In order for B to instantiated by the JVM, it must not be abstract. A abstract class is an idea or suggest of how a class might work, with some (or all) of the functionality needing to implemented by those classes that extended it.
For B to be instantiated, it must implement all the abstract methods of A.
To solve your problem, you must provide an implementation of the methods that A has marked as abstract...
public abstract class A {
public abstract void implementMe();
}
public class B extends A {
public void implementMe() {
// Your implementation
}
}
The reason for much of this is it allows you to pass B to methods and classes that use A and also change the way in which A works. This is part of polymorphism, where one instance of object can act as its parent (B acting like it's A)
I don't know if it will help, but you could have a read of Abstract classes
and methods
don't declare method act in abstract class A as abstract method if you do not want to provide implemenation of act in B. But that may not be a right choice depending upon what you are trying to achieve. In second case, when abstract class extends another abstract class, use "implement" instead of "extends". hope it helps
In my application I have a class, let me call it class A. Four classes, let me call them B , C, D and E extend from this class. Each of these four classes has an interface that its functionality is same.
I want to know if I put this interface in class A all of these classes have access to it. Am I right?
I have another class, G that is implementing this interface. If I implement this interface does it apply to those four libraries at same time?
Update
Let me go into detail.
I have four classes. Each class has a method that when this class connects to internet will set a flag. like this.
public class ClassB extends {
public interface OnConnectingToServer {
public void onGettingDataFromServer(boolean flag);
}
public ClassB () {
if(I'm_downloading_from_internet)
OnConnectingToServer.onGettingDataFromServer(true);
}
}
I have this situation for "B", "C", "D" and "E" classes. Class "G", implements this interface. If I want to put each interface in each class therefore, i need to assign four different names ans in "G" class also implements 4 interfaces.
I think this way is not a good way.
I'm looking for a way that instead of implementing 4 same interfaces, implementing just one interface. therefore, regardless of triggering the interface by one class or all four classes, just one implementation is done.
Hope to make it more clear. Thanks again.
Don't put the interface definition inside class A. Make it a separate top-level type and then make all your classes implements MyInterface. If class B extends A, then you don't have to explicitly say implements MyInterface since there is no way for a subclass to "unimplement" an interface.
Yes, if you let A implement an interface, then all classes that extend that class also implement that interface.
Not entirely sure what you mean with letting G implement the interface. Doing that will only affect classes that extend G.
Briefly, yes. From the Java Language Spec:
A class may be declared to directly implement one or more interfaces,
meaning that any instance of the class implements all the abstract
methods specified by the interface or interfaces. A class necessarily
implements all the interfaces that its direct superclasses and direct
superinterfaces do. This (multiple) interface inheritance allows
objects to support (multiple) common behaviors without sharing any
implementation.
(my emphasis)
If you implement the interface (call it I) in class A and B, C + D extend A then B, C and D will implement the I interface as well.
This means you will be able to write:
I aInstance = new A();
I bInstance = new B();
but also:
A aInstance = new A();
A bInstance = new B():
because logically your data model will become:
A is an I
and
B is an A
so this implies:
B is an I
If class G implements the interface but doesn't inherit A you will have to implement the functionality defined in I in the class G as well.
This means you will be able to write:
I aInstance = new A();
I gInstance = new G();
but not this (this won't compile): A gInstance = new G();
Just remember, the interface is only a contract. Any class that implements an interface is bound to respect the contract but no implementation is inherited (no implementation can exist in the interface anyway).
What I mean is:
interface B {...}
interface A extends B {...} // allowed
interface A implements B {...} // not allowed
I googled it and I found this:
implements denotes defining an implementation for the methods of an interface. However interfaces have no implementation so that's not possible.
However, interface is an 100% abstract class, and an abstract class can implement interfaces (100% abstract class) without implement its methods. What is the problem when it is defining as "interface" ?
In details,
interface A {
void methodA();
}
abstract class B implements A {} // we may not implement methodA() but allowed
class C extends B {
void methodA(){}
}
interface B implements A {} // not allowed.
//however, interface B = %100 abstract class B
implements means implementation, when interface is meant to declare just to provide interface not for implementation.
A 100% abstract class is functionally equivalent to an interface but it can also have implementation if you wish (in this case it won't remain 100% abstract), so from the JVM's perspective they are different things.
Also the member variable in a 100% abstract class can have any access qualifier, where in an interface they are implicitly public static final.
implements means a behaviour will be defined for abstract methods (except for abstract classes obviously), you define the implementation.
extends means that a behaviour is inherited.
With interfaces it is possible to say that one interface should have that the same behaviour as another, there is not even an actual implementation. That's why it makes more sense for an interface to extends another interface instead of implementing it.
On a side note, remember that even if an abstract class can define abstract methods (the sane way an interface does), it is still a class and still has to be inherited (extended) and not implemented.
Conceptually there are the two "domains" classes and interfaces. Inside these domains you are always extending, only a class implements an interface, which is kind of "crossing the border". So basically "extends" for interfaces mirrors the behavior for classes. At least I think this is the logic behind. It seems than not everybody agrees with this kind of logic (I find it a little bit contrived myself), and in fact there is no technical reason to have two different keywords at all.
However, interface is 100% abstract class and abstract class can
implements interface(100% abstract class) without implement its
methods. What is the problem when it is defining as "interface" ?
This is simply a matter of convention. The writers of the java language decided that "extends" is the best way to describe this relationship, so that's what we all use.
In general, even though an interface is "a 100% abstract class," we don't think about them that way. We usually think about interfaces as a promise to implement certain key methods rather than a class to derive from. And so we tend to use different language for interfaces than for classes.
As others state, there are good reasons for choosing "extends" over "implements."
Hope this will help you a little what I have learned in oops (core java) during my college.
Implements denotes defining an implementation for the methods of an interface. However interfaces have no implementation so that's not possible. An interface can however extend another interface, which means it can add more methods and inherit its type.
Here is an example below, this is my understanding and what I have learnt in oops.
interface ParentInterface{
void myMethod();
}
interface SubInterface extends ParentInterface{
void anotherMethod();
}
and keep one thing in a mind one interface can only extend another interface and if you want to define it's function on some class then only a interface in implemented eg below
public interface Dog
{
public boolean Barks();
public boolean isGoldenRetriever();
}
Now, if a class were to implement this interface, this is what it would look like:
public class SomeClass implements Dog
{
public boolean Barks{
// method definition here
}
public boolean isGoldenRetriever{
// method definition here
}
}
and if a abstract class has some abstract function define and declare and you want to define those function or you can say implement those function then you suppose to extends that class because abstract class can only be extended. here is example below.
public abstract class MyAbstractClass {
public abstract void abstractMethod();
}
Here is an example subclass of MyAbstractClass:
public class MySubClass extends MyAbstractClass {
public void abstractMethod() {
System.out.println("My method implementation");
}
}
Interface is like an abstraction that is not providing any functionality. Hence It does not 'implement' but extend the other abstractions or interfaces.
Interface is the class that contains an abstract method that cannot create any object.Since Interface cannot create the object and its not a pure class, Its no worth implementing it.