Switching from abstract class to interface

Question

I have an abstract class which has all abstract methods except one which constructs objects of the subclasses. Now my mentor asked me to move this abstract class to an interface.

Having an interface is no problem except with the method used to construct subclass objects. Where should this method go now?

Also, I read somewhere that interfaces are more efficient than abstract classes. Is this true?

Here's an example of my classes

abstract class Animal {
    //many abstract methods
    getAnimalobject(some parameter) {
        return //appropriate subclass 
    }
}

class Dog extends Animal {}
class Elephant extends Animal {}

Answer 1

That construction method should go in a new Factory class.

In object-oriented computer programming, a factory is an object for creating other objects. It is an abstraction of a constructor, and can be used to implement various allocation schemes. For example, using this definition, singletons implemented by the singleton pattern are formal factories.

A factory object typically has a method for every kind of object it is capable of creating. These methods optionally accept parameters defining how the object is created, and then return the created object.

Factory objects are used in situations where getting hold of an object of a particular kind is a more complex process than simply creating a new object. The factory object might decide to create the object's class (if applicable) dynamically, return it from an object pool, do complex configuration on the object, or other things...

Answer 2

Your design is a bit unorthodox, Animal::getAnimalobject() is inherited to Dog and Elephant unnecessarily. What you need to do is:

1. Move all the abstract functions in the interface,
2. Have your Dog and Elephant classes implement an Animal interface,
3. Continue creating them via a factory method, as you currently do.

...and you'll probably want to rename Animal (the class) to AnimalFactory.

Answer 3

Also, I read somewhere that interfaces are more efficient than abstract classes. Is this true?

No, neither are more efficient then the other.

Abstraction gives you better inherited behavior changes of class, since you only have to make changes in one place. Where as, interfaces allow you to separate the behavior of a class into multiple descriptions.

This is because a class can only extend one abstract class. So all of the behavior of the abstract class is inherited, where as a class can implement multiple interfaces which allows that class to represent multiple behaviors.

Having an interface is no problem except with the method used to construct subclass objects. Where should this method go now?

Maybe something like this.

interface Animal {
  getAnimalobject(parameter);
}

class Dog implements Animal {
   function getAnimalobject(parameter) { return .... }
}

class Elephant implements Animal {
   function getAnimalobject(parameter) { return .... }
}

Lots of reasons why this is better then abstraction, but I don't want to really write them all down. Here are my top reasons for interfaces over abstraction.

Top Reasons To Use Interface

1. Abstracted classes can create object and memory management problems. For example; if you create an abstract class called "List" and it had an abstract method called "Remove". When you implement your own "Remove" method, should you delete memory or keep it? You simply don't know what the base class is doing, or what it will do in the future. If someone modifies the base class to handle the list differently, then you could likely break things in your class.

2. Interfaces are easy to use in testing. Creating mock objects of an interface is far easier then creating a mock object of abstract classes.

3. Objects can implement multiple interfaces but only one abstract class.

4. Changes to an abstract class can cause a cascade of failures across multiple classes, or worse just one small hidden failure in a rarely used class.