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 <swmc...@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.bergm...@me.com> wrote: >> >> >> >>> Am 06.02.2021 um 21:44 schrieb Luís Oliveira <luis...@gmail.com>: >>> >>>> On Sat, 6 Feb 2021 at 20:07, Rudi Araújo <rudi.ara...@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 >