Video recording and production done by Barcelona Ruby Conference.
Design Patterns often are discussed with a negative tone. We laugh at Java developers and their heavy classes with the patterns encoded in the name. After all, who wants to try to understand the AbstractBaseClassFactoryManager? But don't most Ruby developers spend their time in a framework that glorifies a select few patterns to the point where the idea of writing code outside these patterns is considered heretical? On the other hand, Evolutionary Design says we are supposed to let the design come out over time, listening to the feedback we get from the combination of tests and refactoring, planning as little ahead as possible. What's a developer to do? Ideally, Design Patterns are used as communication, not construction, as description, not prescription. In this talk, we'll discuss using patterns as a goal, as guides when iterating and evolving our system's design. Rather than thinking "I'll solve this with a strategy pattern," we can say that our design is heading "towards a strategy pattern" or we ended up with a "strategy-like" design. Through the course of our time together, we'll look at some common refactoring decisions that are influenced by a strong familiarity and appreciation of design patterns. Design Patterns can be our friends, if we just know how to use them appropriately.