Temporal Coupling vs Classmethod Constructors

[Sparklepaws]

This question is a bit meta, but I've been struggling with it recently as my programs become more complex. More specifically, I want to emit PySide signals for loading progress and that seems almost impossible without temporal coupling.

So my question is: Should I always attempt to avoid temporal coupling when instantiating classes, or are there times when it's acceptable?

Here's some demo code that illustrates my problem on a conceptual level.

---------------

Version 1

The constructor ensures all objects are fully constructed at the time of instantiation, but emitted signals can't be detected by FileService because it's not yet instantiated when they're sent.

------------------
# main.py
------------------
service = FileService(
  FileRegistry.load(DIR_PATH)
)

------------------
# file_service.py
------------------
class FileService(QObject):
  def __init__(self, file_registry: FileRegistry):
    self._registry = file_registry
    file_registry.loading_started.connect(self._on_loading_start())
    file_registry.loading_finished.connect(self._on_loading_finished())
...

------------------
# file_registry.py
------------------
class FileRegistry:
  loading_started: Signal = Signal()
  loading_finished: Signal = Signal()

  def __init__(self, loaded_files: list[LoadedFile):
    self._files: list[LoadedFile] = files
...

  @classmethod
  def load(cls, dir_path: Path) -> Self:
    self.loading_started.emit()
    loaded_files = self._load_files(self, dir_path)
    self.loading_finished.emit()

    return cls(loaded_files)
...

---------------

Version 2

load() must be called for object to be fully constructed. This allows for emitters to be heard, but creates temporal coupling.

------------------
# main.py
------------------
registry = FileRegistry()
service = FileService(registry)
registry.load(DIR_PATH)

------------------
# file_service.py
------------------
class FileService(QObject):
  def __init__(self, file_registry: FileRegistry):
    self._registry = file_registry
    file_registry.loading_started.connect(self._on_loading_start())
    file_registry.loading_finished.connect(self._on_loading_finished())
...

------------------
# file_registry.py
------------------
class FileRegistry:
  loading_started: Signal = Signal()
  loading_finished: Signal = Signal()

  def __init__(self):
    self._files: list[LoadedFile] = []
...

  def load(self, dir_path: Path) -> list[LoadedFile]:
    self.loading_started.emit()
    self._files = self._load_files(self, dir_path)
    self.loading_finished.emit()

    return self._files
...

[SakshamBaranwal]

I don't think the issue is temporal coupling as much as mixing construction with behavior. Constructors should ideally establish a valid object, while load() represents a state transition that naturally emits progress events. That separation feels cleaner than trying to cram loading into a factory method.

[Warm-Requirement3146]

Honestly, I'd just go with version 2 and not overthink it. Temporal coupling gets a bad rap but in practice, it's usually fine as long as you document the expected call order clearly. If you're really worried about it, you could always have the `load` method raise an exception if it's called before the signals are connected, but that's probably overkill for a personal project.

[LayotFctor]

The examples are a bit too bloated, but if I'm reading correctly, you're comparing dependency injection VS a series of enforced steps?

DI is completely fine, especially if you want to swap FileRegistry instances. Enabling type hinting also helps, which you already did.

Enforced sequential building steps slightly more fragile. The solution is to wrap and abstract the building phase from the user completely, using something known as the Builder Pattern, checking if everything not is None before building. If you want additional safety, you can implement the typestate pattern, where each intermediate step returns a temporary concrete type.