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!
dont you think the Facade class you have is trying to be a AllEncompassing facade ? 2000 method signatures is too huge to be in any class. I would definitley break this down into N number of facades based on functionality. That would first, partition your application better and solve some of your maintainability problems.
My 2 cents..
Putting this many methods in a facade is not a good approach. You should think about splitting into several facades and group the methods based on their functionality. You can also look at the command pattern instead and have a central point of access (Session Bean) to delegate to the Command Session bean at run time.
How many subsystems are behind your facade? This is only a very rough estimation since I don't know the domain, but with 2000 method signatures I'd generally expect about 150-250 classes over about 10-20 subsystems. Each one could then have its own facade (in line with Raj's suggestion), and I would attempt to simplify the API exposed by each one by means of the strategy pattern.
In practice these strategies often resolve to the command pattern that Brian indicated.
Hi All, thanks for the replies.
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?
I dont think you will be breaking the facade pattern by having multiple facades and more importantly Patterns are just to make software more organized and easier to maintain. You should definitely have at least one facade for each subsystem you have so that work can be distributed based on subsystems and yes you should be wary about the coupling between the different facades(if there is some).