Does something like this make any sense at all in Java?
class A<T extends B> extends T{
int fun1() {
....
}
}
abstract class B extends X implements C {
}
interface C {
int fun1();
}
I want class B to extend both X and C ideally. But since there is no multiple inheritance in Java, I'm trying to come up with a slicker workaround.
The trick is that the stuff that would be defined in C is defined in Super Class "A" instead. The problem is to get A let me use a generic type after "extends"
Thoughts?
No, you can't make a type extend a class specified as a type parameter
Without knowing what A, B, C or X are, it's very hard to recommend an alternative design pattern I'm afraid.
What you're trying to do is not going to work - Java generics have nothing to do with inheritance. There is no multiple inheritance, you'll have to make your peace with that :-)
You can declare multiple interfaces and use aggregation to "fake" multiple inheritance.
As others have said, generics won't help you with multiple inheritance of implementations.
My workaround for not repeating myself due to multiple inheritance is usually to write the common implementation in a static method in the superclass, and delegate to that from the places where it is needed.
The simplest example would be like this:
class A
{
}
class B extends A
{
}
interface C
{
void foo();
}
class CBase extends A implements C
{
public void foo()
{
sFoo(this);
}
static void sFoo(C c)
{
// Implement foo here
}
}
class D extends B implements C
{
public void foo()
{
CBase.sFoo(this);
}
}
Note that to make this useful there would be more operations inherited by D from B and A, which are not shown in this example.
The type parameter is only a placeholder for the compile-time-only generics, it is an actual type.
Trying to come up with a workaround solution for multiple inheritance in a language that does not support it is probably a good indicator that the flaw is in the design. Saying A<T extends B> extends T will obviously fail as it doesn't even mean what you're hoping it to mean - <T extends B> means only that T is of a type that is a B. Appending extends T does not mean anything because T is not defined in that class. Again, this is a compile-time type - the actual type of T is not directly available during runtime.
Are you really sure that what is most properly achieved via multiple inheritance as opposed to composition? It could also be possible that you're trying to get A to do too many things.
A more concrete example might allow others to give more feedback on the design itself.
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 programming with java.
Let's say I have an "MyInterface" interface, and a "MyClass" abstract class.
I want to ensure that every class implementing the "MyInterface" interface is inherited from "MyClass".
An inherited class from MyClass is perfectly able to NOT implement the "MyInterface" interface.
Is this possible ? Thanks.
I'm sorry if my english is bad but I'm french.
I want to ensure that every class
implementing the "MyInterface"
interface is inherited from "MyClass".
Nope. That's not possible. The whole point of an interface is to make it so that classes from different inheritance hierarchies can implement support for a pre-defined set of capabilities.
AFAIK, you can't do this directly.
Generics let you say something like this, if it helps:
public <T extends MyClass & MyInterface> void foo(T param) { /**/ }
So, you can only call foo() with parameters that are both MyClass and MyInterface.
Or, why not have two abstract base classes?
abstract class MyClass { /* stuff here */ }
abstract class MyInterfaceClass extends MyClass { /* empty */ }
Then, use MyInterfaceClass instead of MyInterface.
Or, if you just care about containers, write your own:
static class MyList extends ArrayList<MyInterface> {
#Deprecated
public boolean add(MyInterface obj) {
assert obj instanceof MyClass;
return super.add(obj);
}
public <T extends MyClass & MyInterface> boolean add(T obj) {
return super.add(obj);
}
}
Then, you will get a deprecation warning any time you make a mistake.
But my question remains - what problem are you trying to solve? Can you use more descriptive names instead of "Class" and "Interface"? Perhaps the right solution is something completely different..
No, it is not possible. Any class can implement MyInterface. There is no way to limit implementors to subclasses of MyClass.
If you really need a limitation like that I think you'll be stuck with having to not use an interface and instead use MyClass in place of an interface.
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.