According to GOF (Table 1.1, p10), the Facade pattern is an object level pattern, not the class level pattern. But all I see there in the pattern is the introducing a new class (Facade class), and no delegation at all. So I suspect it is a class level pattern. What do you think?
I don't recall what "object level" refers to, but here's how I use it. I have a whole bunch of classes that perform some set of related tasks, let's say they're all in the same package (not required). There's a set of actions someone outside the package, perhaps another subsystem, would like to invoke on these classes. The ideas behinds these actions are pretty simple, maybe getting some data or doing some caluclations. However these tasks, while seemingly simple, are complex in implementation, each class does quite a lot of work internally; and that's why I have broken them into different classes and not one or two big ones. In fact, each request of the external subsystem is handled by a different class. I'd hate to have to have N classes exposed outside the subsystem for N operations. Heck, think of a coupling. Instead I'm going to create a facde. Now, instead of exposing N classes, I expose one class with N methods. The facade class may just be nothing more than a call through. But the user of the facade has a much easier time; and if I need to pass around reference, I can pass around one reference, to the single facade, and not N references. So it makes related classes more manageable form an external point of view. Does that help?
Hi Mark, I am not sure if it is the subject in my previous message that confused you. When I ask "scope of facade", I do not mean how to use the pattern. I take the meaning of "scope of a pattern" from GOF p10. Namely, there are two possible scopes: class level and object level. All I ask is if Facade is class level or object level (according to the definition of GOF p10). Of course, you may tell me you do not care of the "scope" as long as you know how to use if, but to me, I do care.
Hi Da Zhu, The scope of Facade Pattern is indeed at Object Level not at Class Level. You have to introduce a new Facade Class and delegate the calls to the shyer classes, which donot like to talk to the client directly. The best example that I can think of is Session Beans as a facade to Entity Beans.Had the scope of this pattern been at Class Level, it would mean one Session Bean being shared by all clients.Since each SessionBean object is an extended view of the client in the server, every client needs to have its own instance of the Session Bean.Hence Session Bean, which is based on Facade Pattern, has to be at Object Level rather than Class Level. As regards delegation, the SessionBean would find/create the required EntityBean and would delegate the call to it.The advantage of applying this pattern is now you can shield the clients from direct access to Entity Beans basically to reduce network round trips and to improve performance. Hope this helps, Sandeep [This message has been edited by Desai Sandeep (edited June 02, 2001).]
<b>Sandeep</b> <br /> <br /><b>Sun Certified Programmer for Java 2 Platform</b><br /> <br /><b>Oracle Certified Solution Developer - JDeveloper</b><br /><b>-- Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java </b><br /><b>-- Object-Oriented Analysis and Design with UML</b><br /> <br /><b>Oracle Certified Enterprise Developer - Oracle Internet Platform</b><br /><b>-- Enterprise Connectivity with J2EE </b><br /><b>-- Enterprise Development on the Oracle Internet Platform </b>
The way that I distinguish object level and class level patterns, is that if it uses inheritence, then it is a class level pattern. If it uses composition, then it is an object level pattern. Eddy
Joined: Apr 02, 2001
Originally posted by Eddy Chang: The way that I distinguish object level and class level patterns, is that if it uses inheritence, then it is a class level pattern. If it uses composition, then it is an object level pattern.
Could you please elaborate on this taking an example of one class level and object level pattern. Thanks in advance, Sandeep [This message has been edited by Desai Sandeep (edited June 02, 2001).]
Joined: Apr 05, 2001
When I made my reply above, I was going from memory, and I hadn't looked at Table 1.1, p10 of GoF. Now after reading the paragraphs below p10, it looks like my generalization is incorrect considering that most patterns use inheritance to some extent, and I can't come up with consistent examples to validate my statements. I should do more research before posting next time :-) Eddy
[This message has been edited by Eddy Chang (edited June 04, 2001).]
Joined: Apr 02, 2001
Hi Eddy, It is ok.I also donot do much of thinking while posting messages in the forum.Infact,I have never read the GoF book.I had answered to this post by gut feeling.It is just my views or what I think.It may be right or it may be wrong.But I try to compare whatever I had posted with the discussions by peer JavaRanchers to grasp as much as I can. Who knows, your way to distinguish object and class level patterns would be vital and may lead to another approach on this.Please do let me know if you happen to do more research on it. Thanks for your inputs, Sandeep [This message has been edited by Desai Sandeep (edited June 05, 2001).]