[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Abstract classes and interfaces in Lua
- From: Sean Conner <sean@...>
- Date: Fri, 14 Apr 2017 16:15:16 -0400
It was thus said that the Great luciano de souza once stated:
>
> The problem is that Lua is so different that I am not able to
> understand whats the best practices.
> Does we have example of design patterns in Lua? Does GOF patterns make
> sense in Lua?
There's a school of thought that says that design patterns are a sign of
weakness in a language (I follow that school myself [1]). From the
Wikipedia article on Design Patterns [2]:
Significant criticism has been directed at the concept of software
design patterns generally, and at Design Patterns specifically.
A primary criticism of Design Patterns is that its patterns are
simply workarounds for missing features in C++, replacing elegant
abstract features with lengthy concrete patterns, essentially
becoming a "human compiler" or "generating by hand the expansions of
some macro".[4] Peter Norvig demonstrates that 16 out of the 23
patterns in Design Patterns are simplified or eliminated (via direct
language support) in Lisp or Dylan.[5] Related observations were
made by Hannemann and Kiczales who implemented several of the 23
design patterns using an aspect-oriented programming language
(AspectJ) and showed that code-level dependencies were removed from
the implementations of 17 of the 23 design patterns and that
aspect-oriented programming could simplify the implementations of
design patterns.[6]
Paul Graham wrote:[4]
When I see patterns in my programs, I consider it a sign of
trouble. The shape of a program should reflect only the
problem it needs to solve. Any other regularity in the code
is a sign, to me at least, that I'm using abstractions that
aren't powerful enough-- often that I'm generating by hand
the expansions of some macro that I need to write.
It's commendable that you want to follow the best practices for Lua, but
also remember, the map is not the territory.
-spc (Just tossing this out there ... )
[1] I've used design patterns before. One I used quite a bit was
"Register Passing of Parameters" and it worked like this:
Non-pointer parameters are passed in AX or DX
A non-pointer parameter used as a counter passed in CX
Pointers to source data passed in SI or BX
Pointers to data destinations passed in DI
You might not think that is a "design pattern" but it follows from
the GOF book---it is a programming pattern. But such a pattern
doesn't make sense once you start using something other than
Assembly.
[2] https://en.wikipedia.org/wiki/Design_Patterns#Criticism
[3] This footnote intentionally left blank
[4] Wikipedia reference
[5] Wikipedia reference
[6] Wikipedia reference