Of course. I guess many programmers come up with similar solutions without knowing any of the described and written down patterns. But I think it’s good to know them because by giving something a name it’s easier to talk about it.
Manfred > Am 06.02.2021 um 17:51 schrieb Michael Fiano <m...@mfiano.net>: > > I completely agree that most design patterns are the result of deficiencies > in most OO languages and could be solved with Lisp easily, usually with > defmacro. I'd also like to add what the author of one of my favorite books > had to say on the topic: > > Design patterns are purported "master programmer advice" strongly suggesting > to young or otherwise impressionable programmers that the design patterns > convey important concepts, practices, or principles that have been > "prethought." However, design patterns are not "master programmer advice!" > Any master programmer would know that you cannot simply dish out a small > number of generic solutions for generic situations, but that every situation > is (potentially) different and warrants its own (potential) solution. > > On Sat, Feb 6, 2021, at 11:42 AM, Pascal Bourguignon wrote: >> Le 06/02/2021 à 17:35, Pascal Bourguignon a écrit : >>> Now, where would defmacro enter the scene? We could define a few macros >>> and supporting functions to be able to define factories with their set >>> of concrete classes; the macro would expand to the boilerplate code, >>> such as the generic and methods, according to the implementation choice >>> (alist, factory class, factory symbol, etc). >>> >>> >>> (define-abstract-factory gui-factory >>> (window pane button textfield)) >>> >>> (define-factory x11-factory gui-factory >>> (x11-window x11-pane x11-button x11-textfield)) >>> >>> (define-factory x11-factory gui-factory >>> (macos-window macos-pane macos-button macos-textfield)) >>> >>> (defparameter *gui-factory* (make-factory 'x11-factory)) >>> >>> [...] >>> >>> In effect, the abstract factory meta design pattern is thus implemented >>> in lisp as a define-abstract-factory macro, and the concrete abstract >>> factory design pattern as a define-factory macro. >> >> >> I should add that while defining such macros may seem useless given the >> small about of boilerplate they would cover, they offer the advantage of >> providing an abstraction, that would let you change easily the >> implementation at a later time (either to add features, or for >> optimization reasons, etc). >> >> >> -- >> __Pascal Bourguignon__ >> >> >
