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

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.