Let's say I have a small CD burning library written in Python, with a CD class and a Burner interface + implementation classes:# Module cd.pyclass CD:  def __init__(self):    self.folders = []    self.files = []# Module burners/burners.pyBURNERS = []# Module burners/cdburnerxp.pyclass CDBurnerXP(CDBurner):  def burn_cd(self, cd):    # burn baby burnBURNERS.append(CDBurnerXP)If I would like to add a convenient method to class CD:def burn(self):    return BURNERS[0].burn_cd(self)will it cause any problems in the future? Is it considered more coupled than instantiating the burner outside by ourselves?Also, if I wish to add a factory to recreate a CD from a physical drive:# Module factories/drive.pyfrom cd import CDDriveBasedCDFactory(CDFactory):    def create_cd(self):        # stuff        return CD()Will adding a@classmethoddef from_drive(cls):  return DriveBasedCDFactory().create_cd()to CD also cause more coupling? How can I resolve the implicit circular import?
Convenience vs Decoupling/Composition
composition;coupling;python 3.x;abstract factory
The convenience method creates a circular dependency with CD and Burner (which you've seen through the circular import). This is always a design smell, and instead of trying to fix the immediate symptom, you should take a step back and reflect on the design. I think you already have a good design without the burn method on CD. It's very clear that you use an instance of Burner to burn a CD. It allows me as the user to choose which implementation of Burner I want to use, and I can even create my own implementation if yours are lacking. The convenience method on the other hand is extremely inflexible. You can't choose which burner to user--it's tightly-coupled to BURNERS[0]. It may just confuse users. Finally it's difficult to unit test CD.burn because the tight-coupling and globals. The same limitations apply to CD.from_drive.I suggest you have only have one way to accomplish a task. Having a convenience method in CD makes it unclear to the user whether they should use that method or use the Burner instance directly. If you add it now, you'll have to keep supporting it (or break clients), and it will set a poor precedent for other contributors for adding these kinds of methods.As an advocate of anaemic data models I recommend not adding behavior to your CD class and keeping it as pure data--files and folders.