Well, of course not. It’s just one implementation of ‚dependency inversion‘. How does it work in Common Lisp? I really don’t know. Well, I could imagine something. But I’d like to know what you had in mind.
Manfred
Am 06.02.2021 um 22:18 schrieb Scott McKay swmckay@gmail.com:
Nobody in the list community ever invented a fancy pants term like “dependency injection” because it’s so obvious how to do this that nobody thought to give it a name.
—Scott
On Feb 6, 2021, at 4:07 PM, Manfred Bergmann manfred.bergmann@me.com wrote:
Am 06.02.2021 um 21:44 schrieb Luís Oliveira luismbo@gmail.com:
On Sat, 6 Feb 2021 at 20:07, Rudi Araújo rudi.araujo@gmail.com wrote: Class::newInstance() doesn't have any parameters (also, it's deprecated: better to use getConstructor() or getDeclaredConstructor() and call newInstance() on it).
I guess this bit about getConstructor() explains why it'd be more convenient to use a Factory, or the Factory method pattern, or some dependency injection framework.
Yeah. Could be. But this constructor thingy could be hidden in a function similar as you would create a constructor function make-foo in Common Lisp. The reflection stuff is not considered a good practice in certain types of applications.
Dependency injection is about something else IMO. Well, Abstract Factory is about it, too, inversion of control. It allows you to create something without having to know the concrete type and without having to have a source dependency on it. In Common Lisp this could be solved easily by just separating a protocol from the implementation, maybe in separate packages.
Manfred