Pattern, Abstract Factory / Factory

[Manfred Bergmann]

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