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__ > >
