Refactoring to patterns

Refactoring to patterns…. The patterns can be found everywhere around us. They symbolize something universal and useful. Something that worked out as a well-known approach to solving a certain group of problems by its effectiveness and reusability.

In 2015, Ralph Johnson (one of the four authors of the first design patterns book) during his speech titled “21 years of design patterns” said: “We could have done our job better, but I think we did it pretty well.”

Usually, however, the patterns are not perceived as needed in our code from the very beginning. It is probably for good, because the very patterns also introduce an additional level of complexity. However, when our code is getting bigger and more it is more difficult to understand, we start to think in the following terms: “if only the strategy pattern, factory, state instead of if-else or switch networks were used at this point…”

During this training course the participants will examine the examples of refactoring to several well-known design patterns. However, in order to do this within a reasonable time, the examples in this training course have already been partially prepared for this refactoring.

The refactorings presented at the training course lead to the following patterns:

– (Fluent) Builder

– Composite

– Factory Method / Abstract Factory

– Template

– Bridge

– Interpreter

– State (if time permits)

This training course is planned as a continuation of “Effective Refactoring” course. This is based on the premise that pre-processing of the code (missing tests, smaller methods and classes) has already been (partially) made. This is necessary because otherwise we will not be able to notice emerging design patterns from the thicket of legacy code. The course participants will be able to experience how the design patterns can simplify our code, but also how they can complicate it even more through inexperienced use. The fact that applying a design pattern solves the current problems does not mean that it will solve any further problems. Often, in the case of new requirements, the current architecture will become a hindrance – especially when approaching architecture with a copy-paste method without further refactoring. The fact that the design patterns contribute a great value to the projects by reducing complexity (or rather by taking control over it) does not mean that they should be used from the very beginning. This is because the use of patterns simplifies our code only from the point of some degree of complexity. When the patterns are applied too early they themselves will cause additional problems. Hence the issue of using refactoring to design patterns is very important – you have to be able to apply them at the right time, when it is needed.

The training course is very intensive and based on experience (i.e. carrying it many times) the proposed schedule is 2 days / 4 hours per day. Such schedule will also allow the software developers to return to their daily activities for the rest of the day. On request, the training course may also take 1 day (very intensive).

Level: beginner or intermediate, although more experienced software developers repeatedly claimed that they had learned many new things they could then share with the team.

Ask for this course