Facade Pattern Issue - Again


EJB design: Facade Pattern Issue - Again

  1. Facade Pattern Issue - Again (1 messages)

    Hi, at my company we use the Facade pattern for the System Class, therefore every method call passes thru the facade class. Our problem is to manage the class within our team (about 20 developers using CVS) as they need to make changes several times a day. The issue is that using this pattern we've created (collateral efect) a heavy dependency of ONE SINGLE CLASS, this delays a lot out schedule because sometimes that class stays "locked" by some developer. Are there ways to overcome this problem?

    ps: The Facade Class hold about 2000 method signatures!

    Let me state this:
    1-We do not use EJB, only multi-tyer architecture.
    2-We have about 6 subsystems, about 70 basic classes.

    We thought to brake the system class (facade) into 6 subsystems facades.
    Altought some questions arise:

    1-Are we "breaking" the facade pattern? As we have more than one facade?
    2-The facades can relate among them?

    Another solution we thought was for each subsystem "controller" class put a attrribute in the facade class
    | MySystem |
    | public SubSystemA;|
    | public SubSystemB;|
    | ... |

    so to access method we need to path to the specific subsystems
    ie: MySystem.SubSystemA.insertPerson(Person person);
    and do not "break" and still with an monolith facade class.

    Is this a good solution? What are the pros and cons?
    There is a better way to solve?
  2. Facade Pattern Issue - Again[ Go to top ]

    As far as I see, "MySystem" stops becoming facade, but some kind of facade factory. If it's good for you, fine. It's definitely better than the huge file you described before.

    Regarding your questions -
    (1) I don't think so. The pattern speaks about hiding the detailes of complicated system, not mentioning how many systems there are behind it. I think that even 6 different facades are good (and probably will help to code reusability in the future).
    (2) Why not ?