3 ms·
So, getters? We need X, so we call getX(). getX needs A and B, so it calls getA() and getB(). And so on, until getSomething() just reads input. Please correct m
by twberger 11y ago
So, getters? We need X, so we call getX(). getX needs A and B, so it calls getA() and getB(). And so on, until getSomething() just reads input. Please correct me if I'm reading this wrong.
- tadfisher 11y agoThis is the Inversion of Control pattern, where you inject A and B into X via some external mechanism (such as Dependency Injection). The advantage you gain is that you can swap out A and B for objects with different behavior (such as mocks) without needing to change the implementation of X. This leads to an architecture with a high degree of composability and a low degree of coupling, which is great for large systems.
- juliangregorian 11y agoBut getters and setters aren't inherently associated with IoC nor vice versa.
- tadfisher 11y agoSure they are. Instead of the hosting object determining which dependency to return, some external mechanism is determining such. IoC doesn't necessarily apply only to initialization.
- twberger 11y agoWhen besides mocking would you want to swap out a dependency using an overarching dependency provider rather than an intermediary processor/getter with conditional delegation?
- tadfisher 11y agoTest/dev environments are something else I can think of. For example, you might want a different dependency in a dev environment, but you don't want to write tedious "if (env == dev) return foo else return bar" code in your getter, which also couples the hosting class to the environment in which it's running.