CODEWITHSUNDEEP
.netoopdesign-patterns
Icerman
Icerman

Reputation: 1119

Facade design pattern with states

After implementing a Facade to hide some complex sub systems, we end up having a single class for client. But the problem is this single class still has over 100 APIs. This seems to be against cohesive principle. The facade class also manages states so that objects used among sub systems can be hided. The system consist of sub-systems(e.g. project, policy, user, permissions etc) that I think we might be able to design the facade in a more modular way. Any design patterns that may work well with facade in this case?

Upvotes: 1

Views: 539

Answers (2)

escargot agile
escargot agile

Reputation: 22379

If we go by the principles of Domain-Driven Design, then you can separate your system into stateless services and stateful entities. Combining services and state machines in a single facade is not necessarily a good idea.

By the way, in my opinion, using a facade is almost like forcing procedural programming onto an object-oriented language. A facade is just a set of functions, like a module in a non-OOP language. So generally I try to avoid facades when using OOP, although it's good to be pragmatic.

Upvotes: 1

techuser soma
techuser soma

Reputation: 4877

As you already say, having more than 100 APIs in one class is not a good idea. They can be split into different facade classes. Common functionality can be moved to base classes. This is not a design pattern but core of OO. The state can still be maintained. I am not sure if you are already using the session as a store to save state. If so you can still continue to do so.

You can also use a cache to store a state or use a database. If you are using EJBs then SFSB provides this functionality.

Upvotes: 1

Related Questions