I stumbled upon a question on Quora. The question is: How complicated is the code for Microsoft Windows? The person who answered it shared a link to another question: Why windows is less secure than linux? and shared two images. These images are one of the best examples of high complexity leading you to less security. So here is the linux call trace for apache on linux:

This might seem already complex, but wait until you see the call trace for Microsoft IIS on Windows:

The images describe it all. More complexity usually leads to more bugs and more bugs lead to more security problems. Let’s all hope Windows developers refactor Windows so it becomes more like Linux: simple.

I always read about design patterns. I read and read again and again and again… But the feeling that I have to learn more or understand more never goes away. Every time I dive into a pattern I feel like I’m learning something new about it. So this post is about me trying to grasp design patterns better (again). I started writing this post while spending time around this book: Design Patterns: Elements of Reusable Object-Oriented Software. As the book goes on, I will copy and paste some parts of the book here, while adding my opinions or questions; if I have any. I believe this will strengthen my perception of design patterns and at the same time, it may help some others.

Now, I will try to describe what a design pattern is, with my own (english) words, as I understand it now, at this very moment. Then I will go to wikipedia and/or google and copy and paste the description here and see the difference. I’m hoping there won’t be a huge difference :). Here is my definition of a design pattern:

A design pattern is a method to meet a recurring requirement.

So this is what I came up with. Actually it took me a while. First I had to write it in turkish on paper. Then I had to fix the turkish version, then I had to translate it to english. That was the result. So now I’m googling it and here it is:

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design.

The context of this article is already software engineering and software design so this definition can be shortened to this:

A design pattern is a general repeatable solution to a commonly occurring problem.

I think this sounds better than my definition. I especially like the “commonly occuring problem” part. It is much better than “recurring requirement”. I think I will change my definition after this to: “a method to meet a commonly occuring requirement.” Now the main difference is my “method” is their “general repeatable solution” and my “commonly occuring requirement” is their “commonly occuring problem”. A method vs a solution and requirement vs problem. This can be further discussed but both definitions are pretty close to each other in my opinion.

A much simpler definition can be found in the book:

[A design pattern] is a solution to a problem in a context.

Now that we know what a design pattern is, I will list the design patterns I encountered in the book I mentioned above. This part will be mostly copy/pasting the names and definitions. Here is an overview of 23 design patterns:

• Abstract Factory: Provide an interface for creating families of related or dependent objects without specifying their concrete classes. For a long time I didn’t know the difference between factory pattern and abstract factory pattern.
• Adapter: Convert the interface of a class into another interface clients expect.
• Bridge: Decouple an abstraction from its implementation so that the two can vary independently.
• Builder: Separate the construction of a complex object from its representation so that the same construction process can create different representations. For example, libraries like doctrine use builder pattern to build sql queries.
• Chain of Responsibility: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Thoughts: for example, this is how django middlewares work. It passes the request to the middleware objects one by one, they all handle it or one of them stops the handling process.
• Command: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. What are undoable operations? I don’t really understand this definition.
• Composite: Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
• Decorator: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Decorator pattern is among the most popular ones, at least for me.
• Facade: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
• Factory Method: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
• Flyweight: Use sharing to support large numbers of fine-grained objects efficiently. I had a personal project once where I wanted to code a grid with java swing. I tried to create an object for each square in the grid and ended up with thousands of objects. It killed the process and it was very very slow rendering it. I’m not sure but this pattern may be the solution to that.
• Interpreter: Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. I’m curious about this one.
• Iterator: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
• Mediator: Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
• Memento: Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later.
• Observer: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. In django framework, the signals are an example of the observer pattern.
• Prototype: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
• Proxy: Provide a surrogate or placeholder for another object to control access to it.
• Singleton: Ensure a class only has one instance, and provide a global point of access to it.
• State: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
• Strategy: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. I used this one recently where we had 6 different login scenarios. I divided the strategies to 6 classes with an execute(…) method. I had to create the appropriate strategy object from http post data and call the execute method to log the user in.
• Template Method: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.
• Visitor: Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

After listing them, there is one last thing to do with this list of design patterns: classifying them. There are three main categories: Behavioral, Structural and Creational.

Behavioral patterns describe how the objects communicate with each other and tell us the responsibilities of the objects. These patterns are: Interpreter, Template Method, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor.

Structural patterns deal with the composition of classes or objects. These patterns are: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.

Creational patterns deal with the process of object creation. These patterns are: Factory Method, Abstract Factory, Builder, Prototype, Singleton.

Even now I feel much better about design patterns. My next quest will be one post for each design pattern. For that, I will probably read the book and support it with some online materials and create a post with the combination of both.

Here is a good 7 minute read about one of the most common anti-patterns I encounter: the pyramid of doom. This is one of the first things I write about when creating a coding guideline in a company.

It increases the complexity of the code and thus it decreases maintainability and testability. All the details about why most projects have at least one pyramid of doom are in the article. Here is the link again: https://itnext.io/pyramid-of-doom-the-signs-and-symptoms-of-a-common-anti-pattern-c716838e1819

Below, you can find the example pyramid of doom written in the article and how I would fix it. I added some numbers to “//some code here” lines so that we can understand what moves where.

function login(){ 
    if(user == null){ 
        //some code here 1 
        if(userName != null){ 
            //some code here 2
            if(passwordMatch == true){ 
                //some code here 3
                if(returnedval != 'no_match'){    
                    //some code here 4
                    if(returnedval != 'incorrect_password'){ 
                        //some code here 5
                    } else{ 
                        //some code here 6
                    }         
                } else { 
                    //some code here 7
                }
            } else { 
                //some code here 8
            }
        } else { 
            //some code here 9
        }
    }
}

// How to write it better:
function login(){
    if(user != null)
        return
    //some code here 1
    if(userName == null){
        //some code here 9
        return
    }
    //some code here 2
    if(!passwordMatch){
        //some code here 8
        return
    }
    //some code here 3
    if(returnedVal == 'no_match'){
        //some code here 7
        return
    }
    //some code here 4
    if(returnedval == 'incorrect_password'){
        //some code here 6
        return
    }

    //some code here 5
}

As you can see, there is no more pyramid and there are no else clauses anymore. You just read the code in a straight line and you’re done! Happy refactoring the pyramids of doom everyone.

Factory pattern is one of the most used patterns in software architectural design. But once used, it usually comes with unwanted complexity. The reason for this, is the use of many conditional statements like if or switch.

In our everyday use of factories, when a parameter is passed to the factory’s creator method, implementation goes through n numbers of conditional blocks to figure out what to return. This approach not just increases the complexity but also causes a lack of readability. To prevent this situation, registering a reference type variable that holds the reference to the class into a map will save the code from any type of complexity such as cognitive or cyclomatic…

Here there are two examples written in java and python. In these examples we have a payment system. You can pay by credit card or debit card. In both cases the payment methods are registered into a map and resolved when needed – lazy initialization – without conditional statements.

Here is the java version. You can check out PaymentFactory.java line 12, 13 and 14 to see this kind of usage. 

import java.util.function.Supplier;

public class PaymentProcessor {

    public static void main(String[] args){
        Supplier<Card> creditCard = PaymentFactory.getInstance().get(PaymentFactory.PaymentType.CREDIT_CARD);
        Supplier<Card> debitCard = PaymentFactory.getInstance().get(PaymentFactory.PaymentType.DEBIT_CARD);

        creditCard.get().charge(10.0);
        debitCard.get().charge(10.0);
        creditCard.get().charge(14.0);
        debitCard.get().charge(12.0);
        creditCard.get().charge(11.0);
        debitCard.get().charge(9.0);
    }
}

import java.util.EnumMap;
import java.util.Map;
import java.util.function.Supplier;

class PaymentFactory {

    private Map<PaymentType, Supplier<Card>> paymentList;
    private static PaymentFactory instance;

    private PaymentFactory()
    {
        paymentList = new EnumMap<>(PaymentType.class);
        paymentList.put(PaymentType.CREDIT_CARD, CreditCard::new);
        paymentList.put(PaymentType.DEBIT_CARD, DebitCard::new);
    }

    static PaymentFactory getInstance()
    {
        if (instance == null) {
            instance = new PaymentFactory();
        }

        return instance;
    }

    Supplier<Card> get(PaymentType type)
    {
        return paymentList.get(type);
    }

    enum PaymentType {
        CREDIT_CARD,
        DEBIT_CARD
    }
}

public class DebitCard implements Card {
    @Override
    public void charge(double amount) {
        System.out.println("Debit card charged " + amount + "$");
    }
}

public class CreditCard implements Card {
    @Override
    public void charge(double amount) {
        System.out.println("Credit card charged " + amount + "$");
    }
}

public interface Card {
    void charge(double amount);
}

from enum import Enum


class PaymentType(Enum):
    credit_card = 1
    debit_card = 2


class Card:
    def charge(self, amount):
        raise NotImplementedError


class CreditCard(Card):
    def charge(self, amount):
        print("Credit card charged {}$".format(amount))


class DebitCard(Card):
    def charge(self, amount):
        print("Debit card charged {}$".format(amount))


class PaymentFactory(object):
    payment_list = {
        PaymentType.credit_card: CreditCard,
        PaymentType.debit_card: DebitCard
    }

    @staticmethod
    def get(payment_type):
        assert payment_type in PaymentFactory.payment_list, "Payment type not found in factory."
        return PaymentFactory.payment_list[payment_type]


def main():
    credit_card = PaymentFactory.get(PaymentType.credit_card)()
    debit_card = PaymentFactory.get(PaymentType.debit_card)()

    credit_card.charge(10.0)
    debit_card.charge(10.0)
    credit_card.charge(14.0)
    debit_card.charge(12.0)
    credit_card.charge(11.0)
    debit_card.charge(9.0)


if __name__ == '__main__':
    main()

 

In addition to everything I described above; the main reason I wanted to write about this subject is that when you are new to design patterns and in this specific case, factory pattern, you will probably google it and see tons of examples. In most examples, the factory will use conditionals as I described at the beginning. Then one day, when you are brave enough, you will run a code quality analyzer on your code and it will raise alarms telling you to remove those conditionals. Then maybe(!) you will come to the same conclusion by yourself but you will lose time because you didn’t do it this way in the first place. So I hope someone someday reads this and saves a little bit of time. 

Technology Stack

• OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4)
• Python 3.6.7

Acknowledgements

Berk Kibarer for writing the java version of the code and for helping to write the article.