I very well know that it can be done with the help of interfaces and i have done it many times. But this time my situation is quite difference. I have class A , class B and i need to create another class C which extends both A and B because C should have boths functionality and also note that A and B are not inter related so even i cant say A may extend class B.
I am quite confused what should i do right now. I know we cant change java... but at least there would be some way possible. Even the nearest may also do... please help me out.
Adding more details:- Class B is a standard API while class A is a common exception class that need to be inherited by all exception classes.
Related question:
Why is there no multiple inheritance in Java, but implementing multiple interfaces is allowed? (though my question above is not about why it's not allowed.)
This is typically solved using object composition.
This is also advocated in Effective Java, Item 16: Favor composition over inheritance.
Java restricts a class from having an is a-relation to two (unrelated) classes. It does not however restrict a class from having the functionality of two unrelated classes.
class A {
void doAStuff() {
System.out.println("A-method");
}
}
class B {
void doBStuff() {
System.out.println("B-method");
}
}
// Wraps an A and a B object.
class C {
A aObj;
B bObj;
void doAStuff() {
aObj.doAStuff();
}
void doBStuff() {
bObj.doBStuff();
}
}
(Alternatively you could have class C extends A and only create wrapper methods for B, but keep in mind that it should make sense to say C is an A.)
I have a design pattern that need to be followed and for that its compulsory to extend
This is, as you probably know completely impossible. You could however create proxy classes for A and B that delegate the functionality to the C-instance. For instance by adding these two methods to the C-class above:
class C {
// ...
public A asAObject() {
return new A() {
#Override
void doAStuff() {
C.this.doAStuff();
}
};
}
public B asBObject() {
return new B() {
#Override
void doBStuff() {
C.this.doBStuff();
}
};
}
}
http://en.wikipedia.org/wiki/Adapter_pattern
Your problem is solved by the adapter pattern. I went back to check the wiki document, just to be sure :)
It is not possible to extend two classes, and thus inherit functionality from both, in Java. Your easiest alternative it to "wrap" at least one of the two classes. So, instead of also extending B you can have an instance of B inside C, and declare each of B's methods on C, and pass them through. C would not "be" a B, but it sounds like you just want to inherit functionality. And if that's true of A too, then, well, you should be using this pattern for both A and B and not extending either.
Make use of composition. Class C will contain an instance each of classes A and B.
You may try create class C that will contain one instance of class A and one of class B and their methods (create methods with same names that will just call methods from A and B), it's called Composition - another method in opposite to inheritance. Of course that's in case if you don't need instanceof to work with that C class.
A common oop principle is "choose composition over inheritance", since you can't extend 2 classes I would suggest having one of or both of those classes as members of Class C, that is of course if that works for what you are trying to do.
Maybe you can create a new class D, and have both class A and class B inherit from D?
Change the way you are thinking. Think in interfaces. It means that class A is actually an implementation of interface A' and class B is an implementation of interface B'. And you actually want a class C that implements both interfaces A' and B'. Class C doesn't need to extend anything or to use any particular pattern or whatsoever. It can extend A and delegate some methods to B, or it can extend B and delegate some methods to A. Or it can delegate all methods to A and B - implementation is your decision.
Related
Suppose I have the following code...
interface A{
void a();
}
interface B extends A{
void b();
}
class ImplementOne implements B{
public void a(){};
public void b(){};
}
class ImplementTwo implements B, A{
public void a(){};
public void b(){};
}
Regardless of whether class ImplementTwo implements both B and A, or just B, it would still need to implement method a() in interface A, since interface B extends interface A. Is there any reason one would explicitly do
...implements B, A
instead of just
...implements B
?
There is no difference between the two approaches in terms of behavior. In terms of bytecode information, there is a small difference when it comes to information about implemented interfaces. For example:
Class<?>[] interfaces = ImplementTwo.class.getInterfaces();
for (int i = 0; i < interfaces.length; i++) {
System.out.println(interfaces[i]);
}
would return two class instances when implements B, A is used, whereas when using implements B it would return one instance.
Still, the following returns true using both approaches:
A.class.isAssignableFrom(ImplementTwo.class)
IMO the only reason you would want to specify it explicitly like that is if you were attempting to make the code more easily readable by others who needed to interact with it. That even being said, really, a two-step indirection like this is not so abstract that it's difficult to follow, so I don't really think this would ever have a need to happen.
The most famous example is of the use of the interface Serializable.
This is often repeated for the purpose of: Should the super interface suddenly gets detached from Serializable interface, it's sub-interface will still remain Serializable since it's already defined as Serializable.
This often occurs doing code refactoring. Other than that, there is no difference.
Both variants are exactly the same semantically. You might prefer one over the other for stylistic reasons (for example, to make it immediately clear to the reader of the class that it implements both A and B).
There is no difference in how the code will behave (or compile).
Some people prefer explicitly listing all implemented interfaces even if they are enforced by another interface implemented. It's purely a matter of personal/code style preferences.
Both approaches are equal. You might choose implements A, B instead of implements B to specify whole list of types for object ithout knowledge about A-B hierarchy
In this case it doesn't make difference. But technically you could have two interfaces which are not related one to other with same method declaration. And this implementation would implement method for both interfaces.
I have an interface A with two methods:
public interface A{
method One();
method Two();
}
And I have two options for interface B:
Case 1:
public interface B{
method One();
method Two();
method Three();
}
Case 2:
public interface B extends A{
method Three();
}
Can anyone tell me which of the above two cases is better to implement and why?
Which are the downsides of Case 2?
Edit: In interface B, I need both the methods of interface A. So, I thought extending would be much better.
There are some classes where I need method One and Two only, there I implement interface A. And where I need method One, Two and Three, I implement interface B.
This depends on your logic. Consider these two pairs of interfaces:
interface House {
int doorCount();
int windowCount();
}
interface Automobile {
int doorCount();
int windowCount();
int wheelCount();
}
Nobody in his right mind would derive Automobile by extending a house, because an automobile is not a house with wheels.
On the other hand, in situation like this
interface House {
int doorCount();
int windowCount();
}
int Mansion extends House {
int poolCount();
}
deriving from House makes sense, because Mansion is a kind of House with "additional features".
It depends on what you need to do. If method Three() introduces functionality that from the design point of view should be encapsulated into another unit (such as interface or class) then use 2 if it's similar functionality use 1.
EDIT:
There is also one more option: interfaces don't have extend each other and concrete class may implement them both, but again - depends on what you need
EDIT2:
After your edit it still doesn't make much of a difference. Still class can implement two interfaces or one and still you can use polymorphic assignment on both classes. For example if class concreteA implements interfaceA and clas concreteB implements interfaceB or class concreteB implements interfaceA, interfaceB you can still do InterfaceA classB = new concreteB();
If you go with Case 1, and you already have client code written against the type A, it will fail to work with instances of classes which implement B, and for a purely red-tape reason: B is conceptually an extension of A, but modeled in the Java type system as a disparate type.
Example:
static void existingMethod(A a) {
...work with a ...
}
class ImplB implements B { ... }
public static void main(String... args) {
B b = new B();
existingMethod(b); // compile error for Case 1; Case 2 compiles fine.
}
Therefore it would make much more sense to have your B type extend A.
One way is to look at the type of relationship between A and B.
If B "is a" A, then it would make more sense to go with case 2.
It depends on what you use the interfaces for. If all interfaces that use interface A also use interface B, then you may as well use case 1 and get rid of interface A all together. Otherwise, there is no reason to duplicate code. Duplicating code means that if you change something, you have to change it everywhere, instead of just one place.
If you have A and want to use it, you can go for B extends A. If you extend B from A only because of reuse method declaration, then your concrete class has to implement all 3 methods and that is drawback (not much use) when you are concentrating only B.
I'm porting some Python code to Java, and I am having trouble dealing with the following problem:
I have some classes which need to have abilities A, B, or C. Class 1 needs ability A, class 2 needs A, B and C, and class 3 needs B and C. Most importantly, I want to easily be able to change what class can have what ability in the future.
I solved this problem pretty easily with multiple inheritance in Python. I'm trying to figure out the best way to do it in Java, but I can't come up with as good of a solution. I know multiple inheritance is frowned-upon, so I'd appreciate being taught a better way.
Thanks!
It depends on your actual use case, but have you already considered decorators?
http://en.wikipedia.org/wiki/Decorator_pattern
Multiple-inheritance ain't frowned upon. What is frowned upon is "implementation inheritance" (also known as "code reuse"), because it leads to the unsolvable "diamond problem". And because, well, code-reuse really hasn't much to do with OO.
What you want to do can be solved using multiple inheritance (and, say, delegation if you need to do "code reuse").
interface A {
void move();
}
interface B {
void eat();
}
interface C {
void think();
}
class One implements A { ... }
class Two implements B { ... }
class Three implements B, C { ... }
Any OOA/OOD using multiple inheritance can be trivially translated to Java. The part where you say that you need to change the "ability" all the time is a bit scary: if, say, a Car can move(), why would it suddenly need to be able to think()?
You can use AspectJ's mixin syntax fairly easily to emulate multiple inheritance (and at compile time too). First, declare an interface for the functionality you want to mixin:
public interface A{
String getSomethingForA();
}
then define an annotation which you can use to signify that you want the mixin applied to a given class:
public #interface WithA {}
then add the annotation to the class you want to use:
#WithA
public class MyClass {}
then, to actually add some functionality:
#Aspect
public class MixinA {
public static class AImpl implements A{
public String getSomethingForA() {
return "it worked!";
}
}
#DeclareMixin("#WithA *")
public static A get() {
return new AImpl();
}
}
You'll need to use the aspectj jars and run the aspects as part of your compile process, but this lets you create truly modularized functionality and then forcibly merge it into your classes later. To access your class with the new functionality, do the following:
MyClass obj = new MyClass();
((A)obj).getSomethingForA();
You can apply the same annotation to another class and cast it as well:
#WithA
#WithB //let's pretend we created this with some other functionality
public class AnotherClass {}
AnotherClass anotherObj = new AnotherClass();
((A)anotherObj).getSomethingForA();
((B)anotherObj).andSetSomethingElseForB("something else");
Multiple inheritance is almost always a bad idea, as its effects can usually be achieved through other mechanisms. Based upon your description of the problem, it sounds like you want to
Use interfaces to define behavior (public interface A) in this scenario, each behavior should probably have its own interface.
If 2 behaviors are tightly coupled (say A & B), define an interface that implements those two atomic interfaces (public interface CombinedAandB extends A, B)
Define an abstract base class that implements the interface to provide default implementations for behaviors
public abstract class BaseAB implements A, B
{
#Override
public void A() { add(0,1); }
#Override
public void B() {add(1,0); }
private void add(int a, int b) //it doesn't return. no soup for you.
{ a + b; //If you know why this is wrong, high five yourself. }
}
Define a concrete class that extends the abstract base class, implements another interface, and provides its own behavior.
public class IDoABAndC extends BaseAB implements C
{
//stuff, etc
}
You can define the abilities in interfaces and implement them in your classes.
In java you don't have multiple inheritance, instead you can implement multiple interfaces.
So your class 1 will implement interface A and B. Class 2 will implement interface A, B and C. Class 3 will implement B and C.
If what you need is interface inheritance, then as mentioned before, you can always implement multiple interfaces.
If you're looking for implementation inheritance, you're somewhat out of luck. The best solution is probably to use delegation — replace the extra superclasses with fields, and implement methods that just delegate to those fields. It does require writing a lot of repetitive delegation methods, but it's rather unavoidable in Java (without resorting to AspectJ or other bytecode-munging tricks; careful, this way madness lies …).
This is a bit tangential, but you can have python code running in Java via Jython (http://www.jython.org/). This addresses the porting to Java part, not the solving multiple inheritance part (I think you need to determine which is relevant)
I'm working with a certain API library in Java. It has a base class A, as well as B and C which both extend A. B & C provide similar but distinct functionality, all three classes are in the library.
public abstract class A
{
virtual foo();
}
public class B extends A {}
public class C extends A {}
How do I get elements of A, B, and C in my class? If I use interfaces to implement the classes, there is a lot of duplicate code, and inner classes will not allow me to override existing methods so that the calling interfaces of A, B, and C are preserved.
How do I implement multiple inheritence in Java?
EDIT:
Thanks for edit George, its more clear now, forgot to mention one critical requirement: my classes must have A as a base so that they can be managed by platform API.
To recap, you have:
class A
{
public void foo() {}
}
class B extends A
{
public specificAMethod() {}
}
class C extends A
{
public specificCMethod() {}
}
The above classes are in a library that you can't access or modify.
You want to get the behaviour of both B and C in a third class D, as if it were possible to write:
class D extends B, C
{
}
Right?
What about using B and C instead of inheriting? Do you really need inheritance? You want to call private B and C methods?
class D
{
private B b;
private C c;
}
If you take the general approach of "Prefer Composition over Inheritance", you may find out that one or both of the classes shouldn't be actually "Inherited" anyway. In both cases, do the classes have a strict "is-a" relationship? If you can say "Has-a" out loud and it doesn't sound stupid, you probably want composition.
For instance, if you are implementing a deck of cards, the 3 of spades is-a 3 and it is-a spade, but you can also think of it as it has-a 3 and it has-a suit (spade). Since you can think of it that way, you should probably prefer the has-a interpretation and use composition.
Try to stay away from inheritance trees more than a few objects deep--and if you ever feel the desire to use multiple inheritance, try to work around it. This is one of the cases where Java kind of forces you to design your code to be a little more readable by not supplying a feature (but admittedly when you really want it, it's not there and that can hurt! Some level of mixin would be nice).
Sounds like you want to extend A - call it D - override its foo(), and then have new subclasses E & F that extend D and add their own functionality.
You might think about extracting common interfaces and reusing those. A good IDE with refactoring capability will make it easy to do.
Multiple class inheritance is not possible in Java, however you can use multiple inheritance for interfaces. Using Delegation pattern you can combine behavior of several other classes into one.
Completely different approach is applied in COM: all objects inherit from IUnknown, which has a method that could be translated to Java as:
Object queryInterface(Class<?> clazz)
The simplest implementation of this method can be:
if(clazz.isAssignableFrom(this.getClass()))
return this;
else
return null;
Where single inheritance won't work, it's just enough to add:
else if(class == SomeClass.class) {
return something;
} else ...
This way even most complex multiple inheritance cases can be tackled and you get full control over what is returned and when, so you avoid many problems with 'classical' multiple inheritance from languages like C++, like fork-join problem.
Since Java 1.8 you can use interfaces with default methods. It's very handy and I tend to use it a lot. Covariant return types are supported, too. There are a fiew restricktions (see below), but you dont have to implement the inheritence by your self and let the compiler work for you.
public interface A {
default A foo() {
return this;
}
}
public interface B extends A {
#Override
default B foo() {
return this;
}
}
public interface C extends A {
#Override
default C foo() {
return this;
}
}
public interface D extends B, C {
#Override
// if the return type does not implement B and C
// the comiler will throw an error here
default D foo() {
return this;
}
}
Note that this but note that you cant call super.foo or define fields or private members (until Java 9) since its still interfaces. If you get along with this restrictions, this opens up you a new level of object oriented programming.
I'm using a Java class library that is in many ways incomplete: there are many classes that I feel ought to have additional member functions built in. However, I am unsure of the best practice of adding these member functions.
Lets call the insufficient base class A.
class A
{
public A(/*long arbitrary arguments*/)
{
//...
}
public A(/*long even more arbitrary arguments*/)
{
//...
}
public int func()
{
return 1;
}
}
Ideally, I would like to add a function to A. However, I can't do that. My choice is between:
class B extends A
{
//Implement ALL of A's constructors here
public int reallyUsefulFunction()
{
return func()+1;
}
}
and
class AddedFuncs
{
public static int reallyUsefulFunction(A a)
{
return a.func()+1;
}
}
The way I see it, they both have advantages and disadvantages. The first choice gives a cleaner syntax than the second, and is more logical, but has problems: Let's say I have a third class, C, within the class library.
class C
{
public A func()
{
return new A(/*...*/);
}
}
As I see it, there is no easy way of doing this:
C c;
int useful = c.func().reallyUsefulFunction();
as the type returned by C.func() is an A, not a B, and you can't down-cast.
So what is the best way of adding a member function to a read-only library class?
Natural and frequent dilemma. Read about the composition vs inheritance alternative. Your second alternative is basically a composition, if we think that the object A is passed in the constructor instead of passing it in each method - that is, we would be using composition to implement a wrapper or decorator pattern.
The issue for class C returning a new instance of class A has no trivial solution, as you guessed, as long as class C decides to take responsability of creating the new instance. This is why one should pause and think before typing a "new" statement inside a class, if there is the possibility that this class will be subclassed. In yout example, it would be nice if you could tell class C what concrete class to return ... but how would it know to create it? Well we could pass him an object who knows how to instantiate an object of class A (or a subclass)... I guess you are enough motivated to read about Factories now, and design patterns in general.
There is no unique best answer, but if want a quick one: I'd make a wrapper, B class does not extend A but has a constructor with A as parameter, it delegates its methods (except the own) to the inside object.
When you need to call the method in class C (I'm assuming you cant touch class C), you could write: B b = new B(c.func())
Why not use Composition instead of Inheritance?
class ABetterA {
private A a;
public ABetterA() {
}
// write wrapper methods calling class' A methods and maybe doing something more
}
This way, you could also mimic multiple inheritance...
You have a third option. You could use Scala (a Java compatible language) and its traits, which are mixins by another name.
Another option similar to Brian's sugestion is to use Aspect Oriented Programming (AOP) tool, such as ApectJ, which let you "inject" additional functionality into existing classes, even binary ones. You either preprocess the library jar to get a new one with enhanced classes ("static weaving") or you can do all of this at runtime when the library classes are loaded (so called "load-time weaving"). You can check this AspectJ example.
Even though AOP is normally used to modify existing methods (before, after or around "advices" = code pieces) you can also introduce new members and methods - check AspectJ's Inter-type declarations.
Of course there is the question whether AspectJ is supported at your limited platform.