Patterns are everywhere around us. They are things which proved to be good and common. Why? Because of their values like effectiveness, reusability and beauty.In 2015 Ralph Johnson (one of the authors of “Design Patterns : Elements of Reusable Software Architecture” book) during his talk “21 years of design patterns” told us “We could have done better, but I think we’ve done pretty well”.Usually the patterns are not visible to be necessary at the beginning. But once the codebase grows we begin to miss them and think like “if I only had a strategy / factory / state patterns here instead of the net of if-else / switch statements…”In this training I’d like to show you some examples of refactorings into design patterns. In order to cover lots of patterns the samples are already prepared (cleaned up) so that we can move forward with code refactoring towards them.

The ones covered are

  • (Fluent) Builder
  • Chain of Responsibility
  • Proxy
  • Composite
  • Factory Method
  • Abstract Factory
  • Interpreter
  • Template
  • Bridge
  • State

Therefore please note that this is a continuation of “Effective Refactoring” and is based on an assumption that initial clean-up of your codebase – like simplified conditions, smaller methods and classes in your code – has already happened. Such a clean-up is a must-have step as otherwise you will not be able to notice emerging design patterns out of the mess of your legacy code.

The attendees of this training will experience how design patterns might simplify but also de-simplify the design. How they can solve the problems at current state of design and introduce next issues within the design if the approach to the design is followed with copy-paste approach without further refactorings / thoughts.

Although design patterns give us lots of benefits we should not start with introducing them from scratch. This is because design patterns make our code simpler only behind certain point of complexity. Before this point patterns introduce their own additional complexity.

This is a very extensive training. Based on the experience the proposed approach is make it is as 2 days of 6-7 hours. It can also be conducted as one (very extensive) day but in such a case the scope needs to be limited.

Level : junior and regular developers, although senior developers claim that they’ve learned lots of new things / ideas and shared them with fellow developers.