What are the best practices for Facade pattern?

Question

I have my code working, but I don't know if the way that I implemented it is appropriate. Basically, I want to maintain the pattern without violating it.

The code looks like this:

Package Model (with setters/getters omitted):

public class CA {
    private Integer in;
    private Integer jn;
}

public class CB {
    private Integer kn;
    private Integer ln;
}

public class CC {    
    private static CC instancia;
    private CA a;
    private CB b;

    public static CC getInstancia() {
         if(instancia == null) {
             instancia = new CC();          
         }

         return instancia; 
    }
}

Package Business:

class CCBusiness {

    static CC c = CC.getInstancia();

    void alter(Integer input) {
        c.getCA.setIn(input);
        Integer num = c.getCB.getLn();
    }
}

Package Facade:

class FacadeOne {

void methodOne() {
    CCBusiness.alter(1);
    // And more xxBusiness.xx()
}

The real code is more complex, but to explain my doubts, I think this should work.

In one facade I call several Business objects, but it is appropriate that one Business (in this case, the one of CC class) can modify attributes from other classes (in this case, the ones inside CC)? Should I create CABusiness and CBBusiness?

Because, what I understand, one Business can't call another Business, so the second as to be parametrized to receive the object from FacadeOne (if I create CABusiness and CBBusiness)?

Answer 1

I think some clarifications might help you: The facade pattern helps you to have a single point of access for several classes which are hidden behind the facade and thus hidden to the outside world. Usually those classes form some kind of module or logical unit.

What you are struggling with is the structure behind the facade and their hierarchy. This is hard to analyse without knowing the whole picture, but from the information I have it would be best to have several you your Business classes, which can be individually called from the facade. Creating cross-callings between the Business objects will bear the chance to spaghettify your code.

As for best practices and techniques, the simplest one is to draw a sketch of your classes, which usually clarifies a lot. And you're already half way to UML based documentation. :-)

By the way, avoid giving your classes names like CA, CB... It's the same like naming variables a001, a002... Speaking names do a lot for readability!

Answer 2

By having a Facade you can get away with calling multiple CxBusiness objects and integrating their operations into a meaningful result. That is the purpose of a Facade, to simplify the interaction with the Business layer by hiding away interactions of 5 different components behind a concise and clear operation: methodOne.

For the individual CxBusiness however, you want to avoid cross-calling among each other; otherwise, you will end up with a complex dependency structure that could potentially run into circular references. Keep each CxBusiness as the sole wrapper for each Cx model and you will reduce the number of unwanted side-effects when interacting with them. Any interactions among these will take place in the facade.

Furthermore, enforce this pattern by having the facade depend upon interfaces rather than concrete classes: ICABusiness, ICCBusiness, etc. Then, the only way to access any model should be through these interfaces, and obviously, you should not have a concrete CxBusiness with a ICxBusiness member (no cross-dependencies). Once you put these restrictions in place, the implementation itself will flow towards a more modular and less coupled design.