将类实例分配给python中的类属性是一种好习惯吗？

Question

I'm trying to use class composition in python, and I wonder if it is a good practice to assign a class instance to a class attribute in python. Below are the 2 examples which I have in mind. I appreciate if some experienced programmers could tell me when to use which.

(1)

class A:
   def __init__(self):
      self.x = 10

class B:
   def __init__(self):
      self.y = A()

objB = B()

---

(2)

class A:
   def __init__(self):
      self.x = 10

class B:
   def __init__(self):
      self.y = None

objB = B()
objB.y = A()

Answer 1

Things like this are ALWAYS descriptive! Does every B have an A object? If so, then you'd better use #1. Is B some kind of container, that in THIS case has an A object? Use #2.

As an example, imagine I'm building a map of Tile objects. Each Tile object has a location , which I'm further abstracting into a Location object like so:

class Tile(object):
    def __init__(self, location, *args, **kwargs):
        self.location = location

class Location(object):
    def __init__(self, x, y):
        self.x = x
        self.y = y

x2_y3 = Location(2, 3)
tile = Tile(x2_y3)
tile.location.x # 2

Now I could ALSO do this as:

class Tile(object):
    def __init__(self, location: "(x, y)", *args, **kwargs):
        x, y = location
        self.location = Location(x, y)

class Location(object):
    def __init__(self, x, y):
        self.x = x
        self.y = y

tile = Tile(2,3) # builds its own location object

The second strategy may be preferable in this situation, but I prefer the first because it's more expandable. If later on I move to 3D space I can instead do:

class Location3D(Location):
    def __init__(self, x, y, z):
        self.z = z
        super().__init__(x, y)

tile = Tile(Location3D(2, 3, -1))

In the second strategy, this would fail because Tile s ALWAYS have Location objects. You'd have to monkey-patch Tile to make that work, or build a new Tile3D object that may or may not play nice with other Tile s.

Answer 2

re. 1), I would explicitly pass in the A instance, rather than build it within B.__init__. The reason is that, with non-trivial cases, you will want to have different initialization values for A. Or else you might want a shared A instance - otherwise, it's a 1-1 relationship which is restrictive.

class A:
   def __init__(self):
      self.x = 10

class B:
   def __init__(self, instanceA):
      self.y = instanceA

#fire-and forget A
objB = B(A())

#can still do something with the instance
a = A()
objB2 = B(a)

For example, I often work with B classes that have either a 'manager' or a 'parent' attribute. Say, a Table class that has n Column children. Each column gets a reference to the parent table, they don't make one up on the fly.

Further refinement is possible if you mostly don't need to worry about the a instance's initial values:

class B:
   #instanceA uses a default value of None
   def __init__(self, instanceA = None):
      #assign the instanceA if it was passed or build your own on the fly
      if instanceA is None:
          self.y = A()
      else:
          self.y = instanceA

ps do NOT do this to initiate a default A instance. The default value is only computed once and the same A instance gets assigned whenever you don't explicitly pass in a value.

   def __init__(self, instanceA = A()):
        ....

re. 2) I would not use after-the-fact composition. What if you forget to set the .y attribute? instances should, as much as possible, not require multiple chained calls and modifications before they can be used (pretty much what skrrgwasme said). Python has that flexibility, yes, doesn't mean it should be used without a good reason.

Last, while you don't need to set self.y = None, some Python code analysis tools pick up instance attributes only when they are set on the __init__ method.

Answer 3

I would suggest Method 1 because it more strongly supports encapsulation than Method 2.

Why do we care about encapsulation? In Method 1, objB can be initialized in a single statement, so there are fewer places to chase down initialization bugs. Code that wants to use your class doesn't need to know a series of steps required to initialize it; just a single statement and an argument list. This simplicity leads to fewer bugs and more flexible and maintainable code.

Although encapsulation isn't as strongly enforced in Python as it is in some other languages, such as Java, it is still a good practice.