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 {}

3 Answers 3


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...

  • So it ok to have a factory class just for one function? or is it better than having the abstract class with the construction method?
    – nischayn22
    Jun 26, 2012 at 13:56
  • 3
    @nischayn22: yes. Because otherwise, you get a cyclic dependency between "Animal" and its subclasses. For example, try to put Dog and Elephant in a different library than "Animal" - then you see what I mean.
    – Doc Brown
    Jun 26, 2012 at 14:41

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.

  • that looks like what my mentor suggested, also could you explain a bit about efficiency? should I always take care of unnecessary inheritance?
    – nischayn22
    Jun 26, 2012 at 14:12
  • @nischayn22 Yes you should take care of unnecessary inheritance, (extremely) simply put your concrete objects carry some dead weight, stuff they don't need. That won't make a difference in small numbers, but since you are still learning, you shouldn't make a habit of building unnecessarily resource hungry code.
    – yannis
    Jun 26, 2012 at 14:14
  • @nischayn22 I'm also looking for a solid reference that interfaces are more efficient than abstract classes. I don't think there's a noticeable difference, but I've also heard it before, never given it much thought. If I find a credible reference I'll add it to the answer.
    – yannis
    Jun 26, 2012 at 14:16
  • @nischayn22 Efficiency wise, all things being equal, an abstract class is still a class, one that needs to be instantiated. An interface is a lightweight structure, bunch of names really.
    – yannis
    Jun 26, 2012 at 14:22

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 {

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.