Field components (Loki Components that are used to display a specific form field, like firstname) are quite large classes in the Loki Checkout. This ADR outlines a couple of decisions to make these components easier to handle.
Field components have grown quite large in functionality, because they need to take care of a lot of logic: Saving state, loading state, validation, filtering, customization via the XML layout and much more.
A field component is always part of a specific form of a specific step. For instance, the field firstname might be part of the shipping address in the shipping step. Following this, the component Firstname inherits from a parent class ShippingAddressField which again inherits from AddressField which extends Component. Thanks to this inheritance, any class that extends from ShippingAddressField automatically has a lot of behaviour, while overriding specific things is easy and straightforward.
The parent classes their logic is grouped together in traits (like AttributeBehaviour).
Normally, classes in Magento are instantiated with their dependencies by injecting those dependencies via the constructor, a concept known as constructor injection (or constructor DI). With Loki, the goal is to make it very easy to create your own components but still extend from parents.
To allow for this, the decision was made not to add any dependencies of the parent classes via the constructor. Instead, these parent classes receive their dependencies via specific setter methods, that are automatically called once a component is created via the component resolver.
The only time when components are not instantiated via the component resolver, is when testing components (unit tests or integration tests).