What are some alternatives to inheritance?
Effective Java: Favor composition over inheritance. (This actually comes from Gang of Four, as well).
The case he makes is that inheritance can cause a lot of unseemly side effects, if the extended class was not explicitly designed to be inherited. For example, any calls to super.someMethod() can lead you through unexpected paths of unknown code.
Instead, hold a reference to the class you would have otherwise extended, and delegate to it.
Here is a link to an interview with Erich Gamma where he talks about the concept a bit.
Some alternatives:
Delegation, also known as Composition
Wikipedia article on limitations and alternatives to inheritance
Q:Inheritance seems error-prone. How can I guard against these errors? And, what are the alternatives?
I'm assuming you're playing with Java which has some rules about inheritance.
Implementing interfaces is a common and oft used option. So, for example, if you have a data-source class that talks to a RDBMS, rather than inheriting that class and using it to implement a NoSQL datasource, the both can implement the same interface.
Rather than..
public class RDBMSDataSource {
...
public String loadSomeDataFromDataSource() {
...Do some stuff...
}
}
public class NoSQLDataSource extends RDBMSDataSource {
...
#Override
public String loadSomeDataFromDataSource() {
...Do some other stuff...
}
}
public class DataSourceClient {
public void foo() {
RDBMSDataSource ds = new NoSQLDataSource();
ds.loadSomeDataFromDataSource();
}
}
Which works but is hard to read, you could use this...
public interface DataSource {
public String loadSomeDataFromDataSource();
}
public class RDBMSDataSource implements DataSource {
...
public String loadSomeDataFromDataSource() {
...Do some stuff...
}
}
public class NoSQLDataSource implements DataSource {
...
#Override
public String loadSomeDataFromDataSource() {
...Do some other stuff...
}
}
public class DataSourceClient {
public void foo() {
DataSource ds = new NoSQLDataSource();
ds.loadSomeDataFromDataSource();
}
}
Another option would be composition. Say you have employees and customers. Your two options would be...
public class Person {
protected String name;
protected String address;
...More stuff...
}
public class Employee extends Person {
protected String jobCode;
protected String department;
...More stuff...
}
public class Customer extends Person {
protected String salesPerson;
protected Date registrationDate;
...More stuff...
}
...or...
public class ContactInfo {
private String name;
private String address;
...More stuff...
}
public class Employee {
private ContactInfo contactInfo;
private String jobCode;
private String department;
...More stuff...
}
public class Customer {
private ContactInfo contactInfo;
private String salesPerson;
private Date registrationDate;
...More stuff...
}
Since Java does not have multiple inheritance and you can implement multiple interfaces, you sometimes need to do the above to make sure your development is clean and readable.
I realise this is not Java per se, but Scala (a language running on the Java Virtual Machine) permits mixins (known as traits in Scala).
Mixins allow you to slot some functionality alongside an existing class, rather than within the inheritance tree.
When a class includes a mixin, the
class implements the interface and
includes, rather than inherits, all
the mixin's attributes and methods.
They become part of the class during
compilation
Delegation is an alternative to inheritance.
I think you should try delegation, delegation is an alternative to inheritance. Delegation means that you include an instance of another class as an instance variable. and it plays a beneficial role that it doesn't force you to accept all the methods of the super class.
Try Delegation which is also know as Composition
Also found the new alternative as mixin
The mixins are kind of composable abstract classes. They are used in a multi-inheritance context to add services to a class. The multi-inheritance is used to compose your class with as many mixins as you want. For example, if you have a class to represent houses, you can create your house from this class and extend it by inheriting from classes like Garage and Garden. Here is this example written in Scala:
val myHouse = new House with Garage with Garden
You will get more info about mixin https://kerflyn.wordpress.com/2012/07/09/java-8-now-you-have-mixins/
Related
Lets suppose I have the following classes:
abstract class AbstractEngine{...}
abstract class AbstractTransmission {...}
abstract class AbstractCar {
private AbstractEngine engine;
private AbstractTransmission transmission;
//setters and getters
...
}
class ConcreteEngine extends AbstractEngine{...}
class ConcreteTransmission extends AbstractTransmission{...}
class ConcreteCar extends AbstractCar {
public void move() {
ConcreteEngine engine = (ConcreteEngine)getEngine();
ConcreteTransmission transmission = (ConcreteTransmission) getTransmission();
....
}
}
As you see in ConcreteCar we will have a lot of casting for working with concrete details. It seems to me that I am doing something wrong here. Can I anyhow avoid so many casting using has a relation and inheritance?
You are correct, such downcasts are most often a symptom of a bad design.
In your case - it seems that your abstractions are not good enough.
In other word: your base (abstract) classes should provide all the *behavior that one needs to deal with the corresponding object.
Meaning: to a user of AbstractEngine it should absolutely not matter what implementation is behind that object. Therefore: look into the interface that your abstract classes are offering; and rework them in a way that allows you to do the necessary things without instanceof checks and downcasts.
It might also be worthwhile to look into "splitting" your functionality into a set of interfaces; allowing you for more "fine granular" slicing of functionality.
I think this is a typical example for the usage of generics. You do not need type casting if you modify your code like this:
abstract class AbstractEngine{};
abstract class AbstractTransmission {};
abstract class AbstractCar<E extends AbstractEngine, T extends AbstractTransmission> {
private E engine;
private T transmission;
public E getEngine() {
return engine;
}
public T getTransmission() {
return transmission;
}
}
class ConcreteEngine extends AbstractEngine{};
class ConcreteTransmission extends AbstractTransmission{};
class ConcreteCar extends AbstractCar<ConcreteEngine, ConcreteTransmission> {
public void move() {
ConcreteEngine engine = getEngine();
ConcreteTransmission transmission = getTransmission();
}
}
You should make use of Polymorphism. Try
AbstractEngine engine = getEngine()
This will compile because ConcreteEngine is-a AbstractEngine. Also this is better OOP practice because this way your program will be more flexible to future changes.
Consider the following code:
public interface MyClass {
public final String getMyObject1();
public final String getMyObject2();
}
public class MyClass1 implements MyClass {
private String myObject1;
private String myObject2;
public MyClass1(String myObject1, String myObject2) {
this.myObject1 = myObject1;
this.myObject2 = myObject2;
}
public String getMyObject1() {
return myObject1;
}
public String getMyObject2() {
return myObject2;
}
}
public interface MyClass2 extends MyClass {
public static MyClass2 newInstance(String myObject1, String myObject2) {
return new MyClass2() {
public String getMyObject1() {
return myObject1;
}
public String getMyObject2() {
return myObject2;
}
};
}
}
And I use them like
public static void func(MyClass m) {
m.getMyObject1();
m.getMyObject2();
}
func(new MyClass1(o1, o2));
func(MyClass2.newInstance(o1, o2));
I wonder how they differ and if I only need to read from the values (i.e. to use MyClass as a "struct" to pass values), using the anonymous class can it be a simpler approach?
Otherwise, what are the draw backs?
One core rule of programming: try to not surprise your readers.
Your approach here to use a static class within an interface as "factory" method is very surprising (and believe me: I have seen a lot of Java code).
If at all, the more "common" way of handling such things: create a static class with a slightly similar name, you know, like there is java.lang.Object and java.lang.Objects that carries some useful static helper methods.
And beyond that, there is already a class in Java that helps with arbitrary numbers of "named" values; and that is called a Map!
Finally: there are some good arguments for "DTO"s (data transfer objects) but esp. for "beginners", you should rather look into "real" OO designs; based on the SOLID principles. In that sense: design real classes that exactly model your problem domain; and that provide helpful abstractions. A struct with an arbitrary number of members ... doesn't fall into either category.
The problem here is not the code necessarily but the design. I would be interested to know the real world use case you are trying to design here.
Surely there are limitations in the second approach like you cannot update the value of your objects at all once your class is created as you just have a way to get the value of the passed objects back.
Coming back to Design:
An interface is supposed to be an action which your class can perform if it implements that interface. In your case you are trying to return the value of two instance variables using the two methods in your interface which is a kind of action but it ignores the basic principle of encapsulation.
If your class defines/owns those instance variables it should have the getters and setters for that. You should not require an interface to do that. So ideally your interface should not be required. Any other class which uses MyClass1 object should directly use the getters and setters of the MyClass1.
In my app, I am using realm as a database platform. Realm has been great thus far- super easy to use, make queries, etc.-though, I have two qualms with it that I am trying to work around.
1) Realm does not support inheritance in model object classes which extend RealmObject.
- I am wondering if any developers out there have used composition as a workaround to the inheritance issue and if its worked for them.
- In other words, say I have a class "car" which extends RealmObject and then I have other classes such as "honda", "toyota", etc. Does it make sense to make separate car objects for each of these which contain either a honda, toyota, etc.?
2) Realm only supports getters and setters in model object classes
- My current workaround for this is by creating static methods within the model object classes.
- In other words, say I want to modify a honda's color, I would call something such as, Honda.updateColor(honda, blue).
- ^ Is this sloppy, or is this essentially the only way to handle such methods.
Really any feedback would be great!
A workaround I've used (in a nutshell)
Composition + Interface inheritance would allow you to get some polymorphism benefits back to your realmObjects.
Some code demonstration
interface IPerson {
String getName();
}
class Person extends RealmObject implements IPerson {
String name;
#Override
public String getName() {
return name;
}
}
interface IWorker extends IPerson {
int getSalary();
}
class Worker extends RealmObject implements IWorker {
Person person;
int salary;
#Override
public String getName() {
return person.getName();
}
#Override
public int getSalary() {
return salary;
}
}
Note
PrimaryKeys unfortunately have to be duplicated.
Check this answer of mine to get more details about this workaround.
Java - Is it possible to extend all the subclasses of a class with a single class?
Let's explain it with an example, the actual code is quite more complex. I have an Animal class with its own class hierarchy. Let's say that it has two subclasses: Testarrosa and Viper.
public class Car {
public abstract String getManufacturer();
}
public class Testarossa extends Car{
public String getManufacturer(){
return "Ferrari";
}
}
public class Viper extends Car{
public String getManufacturer(){
return "Dodge";
}
}
I want to extend all the Car subclasses with a RegisteredCar subclass.
public class RegisteredCar extends Car {
private String plateNumber;
public RegisteredCar (String plateNumber){
this.plateNumber=plateNumber;
}
public String getPlateNumber() {
return plateNumber;
}
}
At some point, I should be able to create a new RegisteredCar of a specific subclass. Something like
RegisteredCar c = new RegisteredCar<Viper>("B-3956-AC");
And call the c.getManufacturer() to obtain "Dodge" and c.getPlateNumber() to obtain B-3956-AC. Obviously, I should still be able to create a Car c = new Viper();
That is an example. Having an attribute in Car with null value if not registered is not enough for what I need.
In short, no that is not possible. You have to unfortunately modify your object model.
For example, what about having a Registration class this way:
public interface Registration<C extends Car> {
C getCar();
String getPlateNumber();
}
This way you can extract the information relating to registration in a single class, while maintaining your Car models.
You can then do helper methods like:
Registration<Viper> registeredViper = createRegistration(new Viper(), "B-3956-AC");
As others have said, no thats not really possible and your example could be solved by changing your model
As an alternative to inheritance you could use another class to wrap a Car instance.
I would make Car an interface (though having RegisteredCar extend Car should work too) and then attempt something like the following pseudo code:
class RegisteredCar<T extends Car> implements Car {
private final T car
RegisteredCar(T car) {
this.car = car;
}
... methods for RegisteredCar
... methods from Car delegating to `this.car`
}
Please excuse the somewhat bad code, I don't have an IDE open, and I always mess up generics without an IDE to hand.
Another possible solution is to use AOP, though I don't know how in fashion that is these days as but what you are describing could be a cross cutting concern.
A final alternative might be to use a language that allows for Extensions, Traits, Protocol or some other type of 'mix in'
In java it is prohibited to extends more than 1 class.
You could build chain from classes to extends, for example.
To solve the problem of mutiple inheritance in Java → interface is used
You should avoid inheritance as much as possible. Use abstractions (interfaces) to make your code elegant and maintainable. Just google why extends is evil.
public interface Car{
String getManufacturer();
}
public interface Registerable{
boolean isRegistered();
void register(String plateNumber);
void getPlateNumber();
}
public class Viper implements Car, Registerable
{
//all methods
}
With Generic class approach as described in other answer, you will not be able to use RegisteredCar where your require to pass Car object. e.g. suppose you need to generate some invoice.
Invoice getInvoice(Car c);
In this method you cannot use RegisteredCar as it is not of Type Car. All you API which require Car are not applicable to RegisteredCar. In some cases you may need Plate Number as well as Car, There you may need to keep mapping of Plate Number and Cars. I would suggest following approach based on Decorate Pattern and delegate all Car calls to passed car object
public class RegisteredCar extends Car{
public RegisteredCar(Car c, String plateNumber){
}
#Override
String getColor(){
c.getColor();
}
}
No, it's not like C++. Multiple inheritance is not possible in Java. However you can implement multiple interfaces.
You cannot achieve that with inheritance.
Your best option is making the RegisteredCar type generic, then having a generic instance variable that holds the intended type car:
public class RegisteredCar<T extends Car> {
private String plateNumber;
private T car;
public T getCar() {
return this.car;
}
public T setCar(T car) {
this.car = car;
}
public RegisteredCar (String plateNumber){
this.plateNumber=plateNumber;
}
public String getPlateNumber() {
return plateNumber;
}
}
With this, you will be able to pass into RegisteredCar an object of any type that's a subclass of Car.
As you can notice, I have removed the extends Car part of this class, as it doesn't need to be a subclass of car itself.
Is there a reason, in the real classes, that you couldn't simply add the new feature to the existing base class?
public abstract class Car
{
public abstract String getManufacturer() ;
protected String plate_number = null ;
public String getPlateNumber()
{ return this.plate_number ; }
public boolean isRegistered()
{ return ( this.plate_number != null ) ; }
}
Why do we need constructors and private members in the abstract class? It is not like we are ever going to create an instance of that class.
You will create instances, just instances of a derived class. Those derived classes will still need to call constructors, and can still call members of the abstract class - which may in turn use private members.
Here's an example (not a terribly useful one, but just to show the basic idea...)
public abstract class NamedObject
{
private final String name = name;
protected NamedObject(String name)
{
this.name = name;
}
public String getName()
{
return name;
}
}
public class Computer extends NamedObject
{
private final int processorSpeed;
public Computer(String name, int processorSpeed)
{
super(name); // See, the constructor is useful
this.processorSpeed = processorSpeed;
}
public String toString()
{
return getName() + " (" + processorSpeed + ")";
}
}
I can't say I write abstract classes that often, generally preferring composition to inheritance, but when I do create them I certainly use constructors and private members.
Abstract classes provide a partial implementation of some interface. It's perfectly reasonable to consider that you might want to provide part of that implementation and disallow client code (concrete subclasses) from accessing the specifics - i.e. an extension of the principle of encapsulation.
Marking some members as private forces the inheriting class to call protected methods to access that partial implementation; providing a constructor allows for subclasses to initialise the parent's encapsulated state during their own construction.
Unlike an interface, an abstract class that defines data fields is in fact instantiated in the sense that these data fields are allocated. It is just that they are never instantiated on their own, they are instantiated as part of something bigger - the subclass. So when the subclass is built, the supertype is built as well, which is why you would need a constructor.
Depending on your hierarchy, your abstract class may have a meaning and state. For example, if your application is a school you may have the notion of a person (that has a name and an SSN), but you would have different subtypes for students and for faculty. Because both types of people share certain state structure (name and SSN) you would have both classes extend the Person class. But you would never simply instantiate a person directly.
In addition to Jon's answer, I'd like to mention that abstract classes still go well with composition, if you keep the subclass tree shallow. I.e. it is great for providing a common base class for a few closely related objects, but not for creating a gigantic tree of subclasses.
Why do you need private class? I think that you are confusing abstract classes with interfaces. Unlike interfaces, abstract classes can hold functionality. For example:
public class AbstractBase{
private int num;
public AbstractBase(int number){
this->num = number;
}
public int method(){
return ( this->num * this->templateMethod());
}
public abstract int templateMethod();
}
public class ConcreteDerived extends AbstractBase{
public ConcreteDerived(){
super(4);
}
public int templateMethod(){
return number; //number is the result of some calculation
}
}
In this example, you´ll never explicitly instantiate AbstractBase, but by declaring members and constructors, you can customize the functionality of your classes (this is called template method).
Assuming you're doing ad hoc code or prototyping, you do instantiate abstract classes (or maybe even interfaces) from time to time. They're called anonymous inner classes (one, two) and look like this:
// you have this...
public abstract class SomeClass {
public abstract String returnAString();
}
// ...and this...
public class OtherClass {
public void operate(SomeClass c) {
System.out.println(c.returnAString());
}
}
// ...so you do this:
OtherClass oc = new OtherClass();
// this is one of the reasons why you need to specify a constructor
oc.operate(new SomeClass() {
#Override
public String returnAString() {
return "I'm an anonymous inner class!";
}
});
This example is of course quite redundant but should expose the point. Some existing frameworks even rely on the heavy usage of this behaviour, namely Apache Wicket at least.