Create a subclass, instead, when calling the creation of a class, depending on some logic

Question

The question that I posted initially was lacking so here is an explanation that I hope will satisfy everyone and cancel some down votes that I received on it.

I would like to have an intelligence inside a class, that with the creation of an instance, it is decided that the instance would be of a different class, which is one of the subclasses of this class, according to some logic.

More specifically, I am making a Magic Square solver as a learning exercise and:

• I want to have a MagicSquare class that will contain the logic of a MagicSquare.
• I want to have OddMagicSquare and EvenMagicSquare subclasses of that class that will contain the logics of solving these two types of Magic Squares.
• I want to be able to call the creation of a MagicSquare, providing it's size, n, and have the intelligence within MagicSquare determine which subclass to create an instance of, instead of the generic, top, class MagicSquare.

I understand that the intelligence to determine which subclass (OddMagicSquare/EvenMagicSquare) to create an instance of can be (and perhaps would be easier to implement if it would be) outside of MagicSquare. The reason that I want it to be inside MagicSquare is perhaps a gut feeling. I have a hunch that it would be more clean and tidy this way because the logic of determining which kind of Magic Square a certain Magic Square is, seems to me, to belong in the MagicSquare class.

Answer 1

Not every thing have to be a class.
Execution in the Kingdom of Nouns
why not use a factory function ?

class Car(object):
....

class SuperCar(Car):
....

def CarFactory(max_speed):
     if max_speed > 100:
         return SuperCar()
     else: 
         return Car()

Answer 2

First, since you didn't give an example, here's the familiar toy minimal class hierarchy:

class Base(object):
    def __init__(self):
        print("I'm a base")

class Child(Base):
    def __init__(self):
        super(Child, self).__init__()
        print("I'm also a child")

Now, presumably you want to decide whether to be a Child or not in the middle of, or right after, Base.__init__.

The best way to do that is to not do it; just move the choice earlier. Then you don't need to do any re-classing; you just construct the class you actually want, and know it's going to be initialized as appropriate for that class.

You can either use a factory function:

def basefactory(child=False):
    if child:
        return Child()
    else:
        return Base()

… or an "alternate constructor" method:

class Base(object):
    def __init__(self):
        print("I'm a base")
    @classmethod
    def make(cls, child=False):
        if child:
            return Child()
        else:
            return cls()

Or a custom __new__ method:

class Base(object):
    def __init__(self):
        print("I'm a base")
    def __new__(cls, child=False):
        return super(Base, cls).__new__(Child if child else cls)

The advantage of all of these mechanisms is that __init__ works the way it's supposed to. If someone writes a normal, Pythonic __init__ method that correctly calls its superclass, it won't get trapped in an endless loop.

The only reason to re-__class__ something in the base __init__ would be if you wanted to explicitly prevent the child's __init__ getting called. That's a very rare case, but if it's what you actually want, it's easy:

class Base(object):
    def __init__(self, child=False):
        super(Base, self).__init__()
        if child:
            self.__class__ = Child

Answer 3

Initially I've supplied an answer which is based on changing self.__class__ during __init__(). It was explained to me in the comments that this should be avoided.

Now I am providing an answer that that is based on redefining the base class' __new__:

class Car(object):
    """The base class."""

    def __new__(cls, max_speed):
        if cls is Car and max_speed > 100:
            return object.__new__(SuperCar, max_speed)
        else:
            return object.__new__(cls, max_speed)

    def __init__(self, max_speed):
        self.max_speed = max_speed

class SuperCar(Car):
    """The sub class."""

    pass   

The code responsible for the creation of an instance is in the built in(1) __new__ method. It is called when a class is called (e.g. my_car = Car(100)) and passed the arguments that were given in that call.

When the instanciation of a Car or a SuperCar (due to the inheritance of __new__) is called, the redefined __new__ checks whether the instance to be created is of cls Car and also has a max_speed greater than 100.

If so, it creates an instance of SuperCar, instead of Car, using object.__new__(SuperCar, max_speed) and returns that.

Otherwise, it calls upon the normal, default, built in, __new__ for the creation of this instance, using object.__new__(cls, max_speed) and returns that. This catches the expected case where not max_speed > 100 and also the case where this redefined __new__ is called by the subclass SuperCar (like in my_ferrari = SuperCar(250)).

For the record, here's my former answer:

When you want an instance's class to be changed to one of it's subclasses, depending on some condition, upon creation of that instance, you can use some logic in __init__, like so:

class Car(object):
    def __init__(self, max_speed_kph):
        if self.__class__ == Car:
            if max_speed_kph > 230:
                self.__class__ = SuperCar
                self.__init__()

class SuperCar(Car):
    def __init__(self):
        print 'this car is fast!'

The self.__init__() is for re-initialisation of the instance as it's new class.

Footnotes:

1. Is this really a built-in? I can't see it in the "Built-in functions" topic of Python Documentation.

Answer 4

I think you're misusing subclasses here.

A subclass is supposed to represent a subtype—something whose interface is visibly specialized. That isn't true in the case of odd vs. even magic squares. They both have the same methods, and do the same (caller-visible) things in response to those methods, and so on.

If the difference between an odd magic square and an even one is not what they do, but how they do it, then they aren't subclasses, there's just a single class with multiple policies.

There may be a reasonable MagicSquareSolver type, whose user is the MagicSquare type, which has to interact differently with odd and even subtypes. In that case, you want to make the separate policies into separate classes. You could base them on an abstract base class (which is rarely necessary in Python, but I'll show it anyway just for the hell of it):

class MagicSquareSolver(metaclass=abc.ABCMeta:
    def __init__(self, square):
        self.square = square
    @abc.abstractmethod
    def solve(self):
        pass

class OddMagicSquareSolver(MagicSquareSolver):
    def __init__(self, square):
        super().__init__(square)
        do_odd_specific_stuff(self)
    def solve(self):
        do_odd_specific_solution(self)

class EvenMagicSquareSolver(MagicSquareSolver):
    def __init__(self, square):
        super().__init__(square)
        do_even_specific_stuff(self)
    def solve(self):
        do_even_specific_solution(self)

class MagicSquare:
    def __init__(self, n):
        self.n = n
        self.cells = self.make_cells()
        if n % 2:
            self.solver = OddMagicSquareSolver(self)
        else:
            self.solver = EvenMagicSquareSolver(self)
    def solve(self):
        return self.solver.solve()

However, I think even this is likely overkill. What is the interface to solving a magic square, even from the square's point of view, beyond a single solve method? There might be an answer to that question if, e.g., you're planning to visualize the solution process or turn it into a helper for a GUI game (although even in that case, a solve_one_step method, or a solve generator method, might still be all you need; look at some of the open source Sudoku games for examples). But likely there's nothing.

And this is what yossi's answer (and the rant he linked to) are getting at: if the interface of a class is just a single method named do_it (or a more useful name that has exactly the same information as the class name itself), and there's no state that needs to live outside of an invocation of that method, you don't have a class at all, you have a function, clumsily hidden away. Some languages (notably Java and C#) force you to be clumsy like that, but Python does not; you can just write this:

class MagicSquare:
    def __init__(self, n):
        self.n = n
        self.fill_squares()
        self.cells = self.make_cells()
    def solve(self):
        if n % 2:
            return self._solve_odd()
        else:
            return self._solve_even()
    def _solve_odd(self):
        stuff()
    def _solve_even(self):
        other_stuff()