I have an Android app with an Activity, a Thread and a class to hold data.
I have created an abstract class ActivityTemplate which extends the Activity class and implements some callbacks, e.g. onTouchListener. This also includes some abstract methods.
I have created an abstract class (ThreadTemplate) which extends the Thread class and includes some abstract methods.
I have created an abstract DataTemplate class which holds some data elements and some simple methods to manipulate it.
I can produce my app by deriving three classes, one from each of the 'Template's above, but I really want to be able to roll them all up into a single MyTemplate class from which I can derive my app from.
Sort of:
public class MyTemplate extends ActivityTemplate, ThreadTemplate, DataTemplate
then
public class MyApp extends MyTemplate
But the MyTemplate class will not compile as you can only extend one class.
Any thoughts, or am I asking the impossible?
Use object composition instead of inheritance:
class MyApp {
private ActivityTemplate activityTemplate;
private ThreadTemplate threadtemplate;
private DataTemplate dataTemplate;
}
When using inheritance always ask yourself the question whether your subclass has an "is-a" relationship with the parent. In this case, MyApp is not a template. It has-a template.
Related
In the Immutables documentation it says that:
For advanced use cases, it may be desirable to have builders that produce different types of objects but conform to the same interface, akin to the original Builder pattern. This is achievable by declaring a static nested class named “Builder” which will be extended by the generated builder.
It then provides an example where:
there is an interface that multiple Immutable classes implement called Vehicle
there is an interface for the builders the Immutable class will generate call VehicleBuilder
the two abstract Immutable classes Scooter and Automobile implement Vehicle and have a abstract static class that implements VehicleBuilder.
This is super useful but it means every Immutable implementation needs to duplicate the abstract static class line. Is there any way to push this up into the parent definition?
I've tried making Vehicle an abstract class and moving the abstract static class into it:
public abstract class Vehicle {
public abstract static class Builder implements VehicleBuilder {}
}
However this does not work and the builder on the generated class does not extend it.
I have the following three classes:
public class MyClassA extends FooA<Bar>
public class MyClassB extends FooB<Bar>
public class MyClassC extends FooC<Bar>
The classes FooA, FooB and FooC all extend Foobar<V> (-> public class Foobar<V extends FooY> implements IFoobar<V>) but at different inheritance levels. Furthermore, it is worth mentioning that FooA, FooB and FooC are part of an API, which I am not able to modify. In my classes MyClassA, MyClassB and MyClassC, I am using some properties and methods in the exact same way and as a consequence I want to create a parent class which implements this same behavior. However, I am not sure how I can implement this inheritance scenario via generics.
I thought about something like:
public class MyParentClass<V extends Foobar> extends V
And then I would simply do the following:
public class MyClassA extends MyParentClass<FooA<Bar>>
public class MyClassB extends MyParentClass<FooB<Bar>>
public class MyClassC extends MyParentClass<FooC<Bar>>
How can I make this work?
Whenever you are stuck with "too much inheritance", the correct answer might be the old mantra: prefer composition over inheritance.
In other words: keep in mind that inheritance is more than just putting "A extends B" onto some class declaration; and also remember that the primary intention of inheritance is to express a "is a" relationship; it is not meant as a simple way to avoid code duplication. (yes, code duplication is very important, but using inheritance to achieve it is very often a bad idea!)
In that sense: instead of further adding to this "inheritance jungle"; I would rather step back and see if it makes sense to define some new interfaces that better capture the set of functionality that you need; and create classes that implement those interfaces; not based on inheriting other classes, but by instantiating objects of those classes; and putting around some wrapping.
I have created a class with some methods which is extended already with UnicastRemoteObjects
public class AccountAuthorizationFilter extends UnicastRemoteObject implements Serializable{//methods}
I have another class which is extended by another class
public class DRMSServerImplementation extends DRMSInterfacePOA{}
How to extend the methods of AccountAuthorizationFilter into DRMSServerImplementation ?? Any alternative possibilities excluding the use of objects of that class?
AccountAuthorizationFilter and DRMSServerImplementation classes could implement another interface containing the methods you need to use in both classes.
I have a section of my code where some classes are implementing an interface.
It feels correct, but there is a little duplication among the child classes - namely 3 methods.
So this is screaming out to use an abstract class.
My question is, will there be any cons in using both abstract class and interface in the following situations:
Abstract class to implement the interface and child classes to extend the abstract class
Child classes to extend the abstract class and implement the interface
Or
Should abstract classes and interfaces not be used together at all like this?
It's perfectly normal to use these two together. Consider for instance AbstractList (implementing List) and AbstractMap (implementing Map) in the JDK.
My knee-jerk reaction would have been to have the abstract class implement the interface and then have the concrete classes derive from it:
abstract class Base implements TheInterface {
/* ...shared methods... */
}
class Concrete1 extends Base { }
class Concrete1 extends Base { }
But your question raising the other possibility made me think, and I can't see much of an argument against doing it that way:
abstract class Base {
/* ...shared methods... */
}
class Concrete1 extends Base implements TheInterface { }
class Concrete1 extends Base implements TheInterface { }
Further, I can see an argument for doing it that way, specifically that it removes the coupling between the abstract class and the interface. If you have another class that needs the functionality Base provides but doesn't need to implement the interface, you have the flexibility to do that.
There's also a third option: Composition. You could not have an abstract class at all, but rather have the multiple concrete classes that implement the interface use a common helper class in their implementation:
class Helper {
/* ...shared methods... */
}
class Concrete1 implements TheInterface {
/* ...uses instance of Helper */
}
class Concrete1 implements TheInterface {
/* ...uses instance of Helper */
}
This has that same flexibility, in another form.
I do not think there is a rule of thumb as such. When designing try and follow the SOLID principles to figure out if what you are doing is good or bad. You can find these principles over here. In this particular case, I would think you should ensure you are abiding by the "Open-Close Principle".
Personally I prefer the statement that an abstract class is a background for other classes, so if three other classes have something common, their common ancestor, the abstract class created only for those three other classes, should provide also code from the interface. This would make the abstract class "complete" (in its way) providing all these properties and methods that the three classes share.
However, it finally makes no difference if all of them would implement the same interface. Making abstract class giving everything that is common is in my opinion a more clear way. It's then easier to compare classes by looking only at this what differs.
If every class in Java implicitly extends Object class and multiple inheritance is not possible in Java then how do we even extend any class?
If you extend a class A that class in turn extends Object, so B extends A implicitly also extends Object.
"Java doesn't have multiple inheritance" means that you can't have two different parents, not that your parent can't have a parent.
C++ is an example of a language that lets you do multiple inheritance: http://www.learncpp.com/cpp-tutorial/117-multiple-inheritance/
Multiple inheritance looks like this:
class Teacher: public Person, public Employee
which means 'Teacher extends Person and Employee, inheriting its fields and methods'.
Instead of multiple inheritance, you're expected to create and implement interfaces to represent all the behaviours (or contracts if you prefer) your object supports. Java uses this for interfaces like Closeable and Serializable.
Multiple Inheritance is the concept of a single class inheriting from two or more super classes. If a class inherits from a super class and if that super class inherits from another super class it does NOT qualify as Multiple Inheritance. It is still Single Inheritance.
once u create object of sub class the object hierachy would be create on order of
objectclaass–>superclass—>subclass;
It is true that every class in Java inherits from the Object class – either indirectly or directly.
so in this case the sub class indirectly inherits object class.
Every Class that dosn't extends any other class it extends Object class.
if you extends anther class example extends Vector class
look to the hierarchy of class Vector you will end with a simple class that dosn't extends any anther class which explicitly extends Object.
and Any class extends anther class it explicitly extends all class that the parent class extends.
There is no multiple inheritance in Java, but there is class hierarchy. Inheritance in Java is transitive: if class A extends Object and class B extends A, than by transitivity A extends Object.