1) a guide for how to build/create something. 2) a describable and characteristic arrangement.
Both can be applied to "design patterns". ie, I'm going to solve a code reuse problem, should I use the strategy or template pattern. Or I'm going to solve this code reuse problem in a novel way in my inheritance based language. I know I'll make an abstract base class that does the reusable stuff and uses some abstract methods to fill in the changing stuff.
So really when people say that "design patterns" are bad, what they really mean are 1) the GoF patterns are only necessary because your language is flawed or 2) people are picking the wrong patterns to solve problems.
But all languages and software systems have patterns, they just might not be cataloged in GoF.
Edit: Thomas, I can't reply since this has been flagkilled, but for you or I an implicit pattern is superior. That said, many business programmers don't come from a functional background and for those programmers I prefer to make my code easier to read.
But in Ruby, you can define instance variables on class objects, so that's where I put my registries. Let's say I have a custom logging class, named Logger, and I have three different logs that need to be accessed. What I would do is define self.[] on Logger, that accesses @loggers on the Logger class itself. So whenever I need a file logger, I just call Logger[:file] rather than LoggerRegistry.get_logger(:file)
Note that an instance variable on a class is different from a class variable. A class variable in Ruby is shared across the all the descendants of the class, and up the chain too to a point. (I don't think they go all the way up to Object but I'm not too clear on the details there.) In practice class variables are rarely used.
For the Factory pattern, the usual way to do it is to define a .create or .build method on the superclass, and have it return or define the needed class. If it were me, I'd use .create to make objects, and .build to make classes.
This is a variation on the "Singleton Pattern" and IMO it is an antipattern. It tightly couples your classes to a "global state" class which makes unit testing very difficult. This is why Dependency Injection was invented. And in Lisp-like languages DI is totally trivial due to having first-class functions and closures.
What I like about using a class object to hold the state is that the class is being depended on anyway, so you're not introducing any 'extra' coupling. I also like to allow the dependency to be passed in as an argument, with the default being to grab it out the registry, for testing purposes or in case I'm hooking into the code with a REPL for whatever reason. This way you get the benefits of DI without littering your classes with keyword arguments that, 99% of the time are only going to interact with one thing.
))))))))))))))))))))))))))