The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

Table of Contents

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

By following the steps outlined previously, we begin to see a more structured solution, predominantly consisting of methods grouped into classes. It’s now time to apply object-oriented principles, such as those encapsulated by the SOLID principles. We analyze the code for patterns of repetition, the need for flexibility, and code smells, and introduce design patterns where appropriate.

In cases where we have many methods with similar patterns, we can potentially use the Template Method or Strategy pattern. When constructing complex structures, the Builder pattern is appropriate. For dealing with simple state machines, the State pattern is beneficial. When polymorphic object creation is necessary, you might use the Abstract Factory or its degenerated form, the Simple Factory.

Example: Refactoring Text Obfuscation Methods

If we observe the TextObfuscatorMethods class from our example, we notice that most methods take the processed text as a parameter. This is an indication that these methods should reside in a class containing a field for the processed text. Essentially, we can invert the situation by placing a field for the processed text within the TextObfuscatorMethods class, thereby making the methods practically parameterless. This gives the class the characteristics of a Builder pattern.

An alternative approach, under the condition that we want the flexibility to compose obfuscating transformations selectively and in any order during execution, would be to apply the Decorator pattern.

Builder Pattern Example:

public class TextObfuscator
{
    private ObfuscatedTextBuilder builder = null;
    // ...
    public string Obfuscate(string text)
    {
        builder.NewText(text);

        builder.ChangeWordsOrderRandomly();
        builder.AddMeaninglessWordsRandomly();
        builder.RemoveSeparators();
        builder.AddSeparatorsRandomly();
        builder.RemoveSpaces();
        builder.ReplacePolishCharactersWithNonPolish();
        builder.ReplaceUpperAndLowercase();

        return builder.ToString();
    }
}

public class ObfuscatedTextBuilder
{
    // ...
    private List<string> textParts = new List<string>();

    public virtual void NewText(string text)
    {
        this.textParts = ParseTextForWordsAndNonWords(text);
    }

    // ...
    public virtual void RemoveSpaces()
    {
        for (int i = 0; i < textParts.Count; i++)
        {
            RemoveSpacesFromTextPart(textParts, i);
            RemoveTextPartIfEmpty(textParts, i);
        }
    }

    public virtual void AddMeaninglessWordsRandomly()
    {
        for (int i = 0; i < textParts.Count; i++)
        {
            if (ShouldAddMeaninglessWords())
            {
                textParts.Insert(i, TextPart.SpaceSeparator); i++;
                textParts.Insert(i, new TextPart(DrawMeaninglessWord(), TextPartType.WORD)); i++;
                textParts.Insert(i, TextPart.SpaceSeparator);
            }
        }
    }
    // ...
}

By employing these design patterns, we enable greater flexibility in our code, helping to achieve cleaner, more maintainable solutions.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

A Simple Introduction to BDD Part 1

A Simple Introduction to BDD Part 1

Today marks the premiere of my screencast, which is essentially my initial foray into video blogging and sharing insights in this format.

Read More

Natural Order of Refactoring Explored Part 2: Compose Method

Compose Method

Analyzing methods, such as the one presented in Part 1, often leads us to understand the main points of the algorithm contained in them. This insight paves the way for the next step: try to split a large method into smaller steps by extracting them into separate methods (refactoring using the Extract Method). Thus, the original method will consist of a sequence of calls to these new methods. With the right naming conventions, you can achieve code that reads like a book.

Read More

Estimation Is Not a Commitment

Estimation Is Not a Commitment

You’ve probably heard that estimation is not a commitment. Sometimes in teams using estimation techniques, some form of accountability for the accuracy of estimation emerges. This is unfavorable for several reasons:
a) firstly, estimation is an approximation (with some probability), not a definitive result;
b) secondly, when accountability kicks in, project games emerge;
c) there are at least several factors causing estimation to differ from the actual time spent on a given task:

Read More