-1

A Facade is a higher level API over a whole subsystem. A God is class that violates SRP. Where do we draw the line? Does the following code represent any of the two:

enum UnitType{Demon, Paladin};

namespace demons
{
    bool are_scary();
    static unsigned numbers;
    void attack();
    void phase_out();
}

namespace paladins
{
    static int morale;
    void attack();
    void retreat();
}

struct Combatant
{
    // Depending on the type of unit
    // and the values of the two global variables
    // calls one of the appropriate functions
    // and perhaps modifies the globals.
    // Is this a proper facade for the 'units' subsystem?
    void attack();
    void retreat();
};

Extremely contrived, I know. What I am trying to illustrate is that a Facade rarely just forwards calls to appropriate functions/methods/types but rather often needs to implement additional logic and that logic encompasses a whole wide system.

Improve this question
6
  • 2
    Your second link already contains a comment (2nd one from above) which explains why a facade and a god object are different things. Did you read it? Good, Now please tell us what question is left open.,
    – Doc Brown
    Jan 1, 2022 at 13:10
  • 1
    A God class is a class that does almost everything itself and is a tangled mess of implicit dependencies (when you change something, you have to hunt down things you have to change in other methods, there's a ripple effect). A Facade is a more focused API to a more complicated "subsystem", but that doesn't mean that the "subsystem" is large (it could be only a couple of classes). It delegates tasks to other objects. A facade offers a simplified interface for the most common usage scenario, but it could also encapsulate the inner workings of the subsystem, or both.
    – Filip Milovanović
    Jan 1, 2022 at 16:33
  • 1
    "often needs to implement additional logic" - Sure but, that logic should mostly be coordination logic (that's the primary responsibility). "that logic encompasses a whole wide system" - Don't make facades that simply try to collect a wide range of functionality in one place. It should have a fairly narrow focus. If it's a facade to a large subsystem, then it should be a high-level type of thing, very limited interface (e.g. application.Run(window)). But again, the subsystem in question doesn't have to be very large.
    – Filip Milovanović
    Jan 1, 2022 at 16:42
  • 1
    I guess another thing to look at it is: The public methods of a God class interact with the various internal components in a haphazard way (in the sense that the interaction patterns are circumstantial - they arise from however the function happens to be implemented by the team member that happens to work on it at a particular time). The classes behind a facade have well-defined interfaces, and the interaction (between them and the facade, and between the classes themselves) happens in well-established ways.
    – Filip Milovanović
    Jan 1, 2022 at 16:48
  • 1
    In all objectivity, we see that the question is clear and specific enough, as there are two very relevant answers, not to count @FilipMilovanović's constructive and informative comments. I vote to reopen it.
    – Christophe
    Jan 2, 2022 at 10:25

3 Answers 3

Reset to default
7

A facade contains the absolute minimum amount of business logic necessary to translate from the outer layer to the inner layer(s); if it contains a significant amount of business logic itself, I'd say it's not a facade but something else - but that doesn't necessarily mean it's a "god object" either.

With all due respect to your example, I think it's too contrived to be useful; if this were a project of any size, the first thing I'd be doing would be to be refactoring both your demons and paladins functionality to be actual objects with no sign of globals or anything like that.

Improve this answer
1
  • Accepting because of the "absolute minimum" phrase. To me this seems objective and translates to "if any of the logic in a Facade serves any purpose but to decide who to delegate to, it's something else". By that virtue my example is definitely not a Facade as it touches globals.
    – Vorac
    Jan 2, 2022 at 13:38
4

Based on your post, you completely misunderstand the concept of a facade. There is no compromise to be made so that a facade doesn't become a "God class." To answer your question, you need to understand first what is a facade, or more specifically, what is the purpose of the Facade Pattern.

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.

You summarized this well in your post. So, it surprises me when you conflate this to "God classes". A facade object doesn't pack all the functionality in it. It simply wraps subinterfaces to simplify the API for its users.

To illustrate, I will use the following analogy. The gear shift in your car is part of a facade that allows drivers to interact in a simple way with a car's transmission. But the functionality of the transmission is not packed inside the facade. A new (simplified) layer is created because drivers are not expert users like mechanics. Therefore, to drive, they make use of this simplified interface to shift gears, for instance. However, mechanics, as expert users, can continue to interact with the transmission class (or interface) directly and call the method that the Shift Gear facade calls internally. So, as you can see, the functionalilty is not packed in the facade.

The conclusion I must reach is simply that, if you have an implementation of the fadade pattern that looks like a "God class", then it was done poorly to say the least. I hope my simple illustration help you understand the difference.

Improve this answer
0

The existing answers already cover the point that the facade contains the minimum of logic, delegating that to other objects; whereas a god object contains that logic itself.

However, it's still possible for a facade to be somewhat god-like. A system may have so many methods available that, even with that minimum of logic, the facade is large and has poor cohesion. This might not technically be a god object, but it could get to a point where it's undesirable for similar reasons.

If this occurs, it might be an indication that the facade pattern is a poor fit for the situation, or that there's another issue. Solutions could include breaking up the facade into a number of more specialised, cohesive objects (taking pragmatic benefit rather than strictly following the pattern), or even breaking the system itself up into smaller systems with their own facades. Or it might be that having everything in one place is beneficial enough to justify a large facade, despite it being unwieldy.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.