Anti-Patterns that assumed as a Pattern(Part2: Facade)

Many persons and pages in internet indicate that this pattern is anti-pattern and its not useful for using in our code. We want discuss about this article and conclude that in which situations this pattern will be anti-pattern.

Maybe the programmer who created this pattern at the first time was an expert in one procedural language. Because we can see the type of thinking of procedural programming in its implementation obviously.

Lets describe this pattern with one example. Imagine that we want convert one file to another format with many method. But we want hide these method from client and prepare just one interface for use our library. For this aim we can use Facade.

For code example I will use this example. First we have a Facade class that hide every thing in itself:

    public class Facade
    {
        protected Subsystem1 _subsystem1;
        
        protected Subsystem2 _subsystem2;

        public Facade(Subsystem1 subsystem1, Subsystem2 subsystem2)
        {
            this._subsystem1 = subsystem1;
            this._subsystem2 = subsystem2;
        }
        public string Operation()
        {
            string result = "Facade initializes subsystems:\n";
            result += this._subsystem1.operation1();
            result += this._subsystem2.operation1();
            result += "Facade orders subsystems to perform the action:\n";
            result += this._subsystem1.operationN();
            result += this._subsystem2.operationZ();
            return result;
        }
    }

And we have 2 subsystem as below:

    public class Subsystem1
    {
        public string operation1()
        {
            return "Subsystem1: Ready!\n";
        }

        public string operationN()
        {
            return "Subsystem1: Go!\n";
        }
    }
    public class Subsystem2
    {
        public string operation1()
        {
            return "Subsystem2: Get ready!\n";
        }

        public string operationZ()
        {
            return "Subsystem2: Fire!\n";
        }
    }

and finally we call our classes:

class Program
    {
        static void Main(string[] args)
        {
            Subsystem1 subsystem1 = new Subsystem1();
            Subsystem2 subsystem2 = new Subsystem2();
            Facade facade = new Facade(subsystem1, subsystem2);
            Console.Write(facade.Operation());
        }
     }

As you can see, its too simple pattern.

But first imagine that we want add another subsystem as below:

public class Subsystem3
    {
        public string operation()
        {
            return "Subsystem3: Added!\n";
        }
}

and change operation() method in Facade class and add this :

result += this._subsystem3.operation();

Oops! We violate second principle of SOLID means “Open for Extension, Closed for Modification”.

So, this pattern usually violate second principle of SOLID when use it alone and we need to combine with other pattern.

Pay attention to above sentence. I do not say this pattern has intrinsic defect. The problem arises from programmer and even we do not use this pattern, again we have that problem. So we can solve it with combination of Facade and other patterns like Pipe & Filter in this case.

But another problem seems already exist. Some programmer believe that wrapper class violate first principle of SOLID. Maybe this part is the most controversial topic in Facade pattern. But in my idea, this comment is not acceptable. Because wrapper class just has one role and one aim: “calling”. It just call other classes and nothing else. And if in special case, you see that it violate S of SOLID, Be sure that without Facade is violated too.

In brief, we can say Facade do not has any violation of any principle by itself. But usually deceive programmers to make mistake. Generally we should use Facade for those codes that adhere all principles.