Creating object outside of facade, breaks the pattern?

Question

I wonder if creating an object outside of facade providing its needed information and than putting it into a facade breaks the pattern?

explanation : usually the objects of the facade are created into the facade itself, however I want to create the object outside of the facade and than pass them into it. And I wonder if its a bad thing to do.

Example:

class A:
    def __init__(self , a ,b, c):
        self.a = a
        self.b = b
        self.c = c

    def do_something_a(self):
        print(self.a, self.b, self.c)


class B:
    def __init__(self, d, e, f):
        self.d = d
        self.e = e
        self.f = f

    def do_something_b(self):
        print(self.d, self.e, self.f)


class Facade:

    def __init__(self, class_a, class_b):
        self.class_a = class_a
        self.class_b = class_b

    def do(self):
        self.class_a.do_something_a()
        self.class_b.do_something_b()

a = A(1,2,3)
b = B(3,4,5)

f = Facade(a,b)
f.do()

I don't understand the question. Can you clarify? Please [edit your question](https://stackoverflow.com/posts/67849521/edit) to include [a minimal, reproducible example](https://stackoverflow.com/help/minimal-reproducible-example). — Mark Seemann, Jun 05 '21 at 13:10

score 2 · Accepted Answer · answered Jun 05 '21 at 15:36

This seems fine; I don't think that it breaks the Facade pattern.

When describing the pattern, GoF discusses a compiler made from various subsystems, such as CodeGenerator, Scanner, ProgramNodeBuilder, and so on. The Motivation section states:

"Some specialized applications might need to access these classes directly. But most clients of a compiler generally don't care about details like parsing and code generation; they merely want to compile some code. For them, the powerful but low-level interfaces in the compiler subsystem only complicate their task.

"To provide a higher-level interface that can shield clients from these classes, the compiler subsystem also includes a Compiler class. This class defines a unified interface to the compiler's functionality. The Compiler acts as a facade"

Here we learn two things:

What a Facade is.
That the subsystem classes that the Facade shields from some clients are still part of the public API of the system, available for those clients that need an extra degree of control.

Later, in the Implementation section, they write:

"The Facade class is part of the public interface, of course, but it's not the only part. Other subsystem classes are usually public as well. For example, the classes Parser and Scanner in the compiler subsystem are part of the public interface."

As a conclusion to the Sample Code section, they write:

"we might want to change the Compiler constructor to take a CodeGenerator parameter. Then programmers can specify the generator to use when they instantiate Compiler. The compiler facade can parameterize other participants such as Scanner and ProgramNodeBuilder as well, which adds flexibility"

The original pattern description clearly describes this as a 'legal' option.

Apart from that, I've also found such a design useful in real life. I've also described a Facade as one design option for a DI-friendly library.

Creating object outside of facade, breaks the pattern?

1 Answers1