144

What I'm talking about here are nested classes. Essentially, I have two classes that I'm modeling. A DownloadManager class and a DownloadThread class. The obvious OOP concept here is composition. However, composition doesn't necessarily mean nesting, right?

I have code that looks something like this:

class DownloadThread:
    def foo(self):
        pass

class DownloadManager():
    def __init__(self):
        dwld_threads = []
    def create_new_thread():
        dwld_threads.append(DownloadThread())

But now I'm wondering if there's a situation where nesting would be better. Something like:

class DownloadManager():
    class DownloadThread:
        def foo(self):
            pass
    def __init__(self):
        dwld_threads = []
    def create_new_thread():
        dwld_threads.append(DownloadManager.DownloadThread())
Obito
  • 391
  • 3
  • 8
fuentesjr
  • 50,920
  • 27
  • 77
  • 81

7 Answers7

166

You might want to do this when the "inner" class is a one-off, which will never be used outside the definition of the outer class. For example to use a metaclass, it's sometimes handy to do

class Foo(object):
    class __metaclass__(type):
        .... 

instead of defining a metaclass separately, if you're only using it once.

The only other time I've used nested classes like that, I used the outer class only as a namespace to group a bunch of closely related classes together:

class Group(object):
    class cls1(object):
       ...

    class cls2(object):
       ...

Then from another module, you can import Group and refer to these as Group.cls1, Group.cls2 etc. However one might argue that you can accomplish exactly the same (perhaps in a less confusing way) by using a module.

dF.
  • 74,139
  • 30
  • 130
  • 136
  • 19
    I -would- argue that in the second case, you would -definitely- be better served using a module or package, which are designed to be namespaces. – Matthew Trevor Sep 17 '08 at 03:51
  • 8
    This is a fantastic answer. Simple, to the point, and mentions the alternative method of using modules. +1 – CornSmith May 08 '13 at 16:19
  • 6
    Just for the record, for those who stubbornly refuse to or cannot organize their code into a hierarchical package and proper modules, using classes as a namespace may at times be better than not using anything. – Asclepius Apr 07 '14 at 19:05
30

I don't know Python, but your question seems very general. Ignore me if it's specific to Python.

Class nesting is all about scope. If you think that one class will only make sense in the context of another one, then the former is probably a good candidate to become a nested class.

It is a common pattern make helper classes as private, nested classes.

André Chalella
  • 13,788
  • 10
  • 54
  • 62
  • 13
    Just to note for the record, the concept of `private` classes doesn't apply so much in Python, but an implied usage scope still definitely applies. – Asclepius Apr 07 '14 at 16:01
17

There is another usage for nested class, when one wants to construct inherited classes whose enhanced functionalities are encapsulated in a specific nested class.

See this example:

class foo:

  class bar:
    ...  # functionalities of a specific sub-feature of foo

  def __init__(self):
    self.a = self.bar()
    ...

  ...  # other features of foo


class foo2(foo):

  class bar(foo.bar):
    ... # enhanced functionalities for this specific feature

  def __init__(self):
    foo.__init__(self)

Note that in the constructor of foo, the line self.a = self.bar() will construct a foo.bar when the object being constructed is actually a foo object, and a foo2.bar object when the object being constructed is actually a foo2 object.

If the class bar was defined outside of class foo instead, as well as its inherited version (which would be called bar2 for example), then defining the new class foo2 would be much more painful, because the constuctor of foo2 would need to have its first line replaced by self.a = bar2(), which implies re-writing the whole constructor.

Thomas
  • 55
  • 1
  • 2
  • 8
  • This answer right now is the single one with a relevant point of view (so, the best one). The scope issue it's to obvious by itself (the question would be whether restricting the scope of class would be beneficial). The other comments are examples of, perhaps, good usages. – Daniel Bandeira Jun 26 '22 at 00:27
  • This is a neat idea, but I'm struggling to think of an application. Why would you want to do this? Why not simply give `foo.bar`'s methods and attributes to `foo` itself, and then override/extend in `foo2`? And do you really need 2 foo classes? Maybe `foo.__init__` should take a bar object as an argument, and the user can choose which version they want. – ibonyun Jan 09 '23 at 23:01
  • @ibonyun A use case I'm looking at has some objects with attributes. When saved, I want a copy to compare "saved" with "current", so I know what's been changed. There's a hierarchy, so some subclasses have additional attributes that the parent class doesn't know about, but the attribute objects still needs to store. – John Bayko May 17 '23 at 19:20
6

You could be using a class as class generator. Like (in some off the cuff code :)

class gen(object):
    class base_1(object): pass
    ...
    class base_n(object): pass

    def __init__(self, ...):
        ...
    def mk_cls(self, ..., type):
        '''makes a class based on the type passed in, the current state of
           the class, and the other inputs to the method'''

I feel like when you need this functionality it will be very clear to you. If you don't need to be doing something similar than it probably isn't a good use case.

tim.tadh
  • 929
  • 6
  • 16
5

There is really no benefit to doing this, except if you are dealing with metaclasses.

the class: suite really isn't what you think it is. It is a weird scope, and it does strange things. It really doesn't even make a class! It is just a way of collecting some variables - the name of the class, the bases, a little dictionary of attributes, and a metaclass.

The name, the dictionary and the bases are all passed to the function that is the metaclass, and then it is assigned to the variable 'name' in the scope where the class: suite was.

What you can gain by messing with metaclasses, and indeed by nesting classes within your stock standard classes, is harder to read code, harder to understand code, and odd errors that are terribly difficult to understand without being intimately familiar with why the 'class' scope is entirely different to any other python scope.

Jerub
  • 41,746
  • 15
  • 73
  • 90
  • 6
    Disagree: Nesting exception classes is very useful, because users of your class can check for your custom exceptions without having to do any messy imports. E.g. ``except myInstanceObj.CustomError, e:`` – RobM Mar 11 '10 at 16:05
  • 3
    @Jerub, why is that bad? – Robert Siemer Aug 18 '16 at 08:56
3

A good use case for this feature is Error/Exception handling, e.g.:

class DownloadManager(object):
    class DowndloadException(Exception):
        pass

    def download(self):
        ...

Now the one who is reading the code knows all the possible exceptions related to this class.

kharandziuk
  • 12,020
  • 17
  • 63
  • 121
0

Either way, defined inside or outside of a class, would work. Here is an employee pay schedule program where the helper class EmpInit is embedded inside the class Employee:

class   Employee:

    def level(self, j):
        return j * 5E3

    def __init__(self, name, deg, yrs):
        self.name = name
        self.deg = deg
        self.yrs = yrs
        self.empInit = Employee.EmpInit(self.deg, self.level)
        self.base = Employee.EmpInit(self.deg, self.level).pay

    def pay(self):
        if self.deg in self.base:
            return self.base[self.deg]() + self.level(self.yrs)
        print(f"Degree {self.deg} is not in the database {self.base.keys()}")
        return 0

    class   EmpInit:

        def __init__(self, deg, level):
            self.level = level
            self.j = deg
            self.pay = {1: self.t1, 2: self.t2, 3: self.t3}

        def t1(self):   return self.level(1*self.j)
        def t2(self):   return self.level(2*self.j)
        def t3(self):   return self.level(3*self.j)

if  __name__ == '__main__':
    for loop in range(10):
        lst = [item for item in input(f"Enter name, degree and years : ").split(' ')]
        e1 = Employee(lst[0], int(lst[1]), int(lst[2]))
        print(f'Employee {e1.name} with degree {e1.deg} and years {e1.yrs} is making {e1.pay()} dollars')
        print("EmpInit deg {0}\nlevel {1}\npay[deg]: {2}".format(e1.empInit.j, e1.empInit.level, e1.base[e1.empInit.j]))

To define it outside, just un-indent EmpInit and change Employee.EmpInit() to simply EmpInit() as a regular "has-a" composition. However, since Employee is the controller of EmpInit and users don't instantiate or interface with it directly, it makes sense to define it inside as it is not a standalone class. Also note that the instance method level() is designed to be called in both classes here. Hence it can also be conveniently defined as a static method in Employee so that we don't need to pass it into EmpInit, instead just invoke it with Employee.level().

Leon Chang
  • 669
  • 8
  • 12