Factory v/s Facade Design Pattern.

Folks,
I was just going thru the Design Patterns (Factory Pattern and the
Facade Pattern)
The Factory Pattern :
The factory completely abstracts the creation and initialization of the product from the client
This indirection enables the client to focus on its discrete role in the application without concerning itself with the details of how the product is created. Thus, as the product implementation changes over time, the client remains unchanged.
Client--------------------->Factory----------------->Product
The Facade Pattern
Encapsulate the subsystem using a High-Level Interface/provides a
simplified and uniform interface to a large subsytem of classes.
The Client communicates with the 'Facade' which has methods to interact
with subsystems.The Client very rarely accesses objects in the subsystems.
Subsystems objects usually retain no knowledge of the client.
Subsystem objects do not normally maintain any reference to Fa�ade.
Client------------------->Facade------->Subsystems
My Question is this:
Arent both these pattern quite similar becos both designs access an Interface
which inturn invokes the required object of the subsystems?
Can anyone explain the major difference?

Perhaps these definitions will clarify things a little for ya...
Fa�ade
The Fa�ade pattern simplifies access to a related set of objects by providing one object that all objects outside the set use to communicate
with the set. This also promotes a weak coupling between the subsystem and its clients. This weak coupling allows you to vary the
components of the subsystem without affecting the clients.
Factory
Centralize the assembly of resources necessary to create an object. This prevents the need to change all classes from changing when a
Product changes and makes any change needed occur only in the Factory.

Similar Messages

Business delegate and Session facade design patterns

Does any one tell me, what is the difference between business delegate and session facade design patterns.

1. Session Facade decouples client code from Entity beans introducing session bean as a middle layer while Business Delegate decouples client code from EJB layer ( Session beans).
2. SF reduces network overhead while BD reduces maintenance overhead.
3. In SF any change in Session bean would make client code change.
While in DB client is totally separate from Session bean because BD layer insulate client from Session beans(EJB layer).
3. In only SF scenario, Client coder has to know about EJB programming but BD pattern no EJB specialization needed.
4.SF emphasizes on separation of Verb, Noun scenario while BD emphasizes on separation of client(presentable) and EJB layer.
Anybody pls suggest more differences ?

Transaction Problem in Session Facade Design Pattern

Hi
Well Sorry for giving wrang title to the topic, coz of which I have not received and reply.
I am using session facade design pattern.
I have Action class calling session facade method "getData" . This method calls "findByPrimaryKey" method in BMP.
Method "getData" has transaction attribute as "RequiresNew" and "findByPrimaryKey" has "Required".
This combination does not assign identity to BMP hence I can not use setter getter method for retriving data(throws nullpointer exception when getter method accessed) I have made sure that I am accessing table and getting data in to BMP but as BMP is not ablle to hoild any identity its not allowing me to use BMP's getter method in session facade.
I have Used Same transaction attribute for create method called by "addNew" method of session facade bean.
Transaction method for "addNew" is "RequiresNew" and for "create" is "Required".
It works fine and gives identity toBMP hense I can use Setter getter method defined in BMP bean.
How can I avoid this and get BMP an identity?
Thanking in Advance,
Chintan.

Sorry, how is this related to JSF?
There's an OO/patterns forum out. Consider reposting the question over there with formatted code.

Facade design pattern example?

Can someone point me to a LabVIEW example of this OOP design? I am learning OOP in LabVIEW and my task is to create an example program using the facade design pattern. I can't find an example to study.
Solved!
Go to Solution.

I'm interested, too, so I posted a link to your question on LAVA. There are a lot of discussions of this sort over there.
Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice

What is meant by session Facade design pattern

please give me

cripes
http://www.google.com/search?q=what+is+meant+by+session+Facade+design+pattern
Who'd have thought it? ;-)
kind regards,
Jos

JDBC Design Patterns

Hi All,
I am new to patterns and have started understanding them using the Head First Series.
I would like to know what all design patterns are there in JDBC?
Can i say that JDBC uses a Facade design patterns as it hides the database specific details and provides us a interface which helps us to connect to a database. What other design patterns exist as part of the JDBC?
Request you to clarify my doubts.
Many thanks in advance

I would really appreciate a good discussion on it
rather than any spoon feeding.
A typical JDBC code will appear as follows:
try
/* Load the jdbc-odbc driver
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
// Open a connection to data source
con
=DriverManager.getConnection("jdbc:odbc:DBName","","")
// Get a statement from the connection
Statement stmt = conn.createStatement() ;
// Execute the query
ResultSet rs = stmt.executeQuery( "select * from
table_name" ) ;
1. Is it ok to look into each statement of the above
code snippet in terms of Design Patterns.it's ok, yes. not necessarily appropriate or worthwhile, though
2. How can one dissect each line of the code in terms
of various design patterns?you can't. design patterns exist at a higher level of abstraction than code. 'in terms of' is also disconcertingly vague.
3. Is it correct to conclude that java.sql package
overall uses Abstract Factory Pattern.
As it uses lot of interfaces and implemetation is
provided by the Vendors. yep. that sounds fair enough. not very useful, though
4. Consider a particular package like
java.sql.Statement,java.sql.Blob,java.sql.Connection
etc. is is correct to conclude that
its an example of a Factory Method Pattern as any
client would instantiate. Here the client would be
Statement object,
Creator is Connection Interface and createStatement()
is the factory method.possibly. there's little value in trying to define everything as a "design pattern", though. rather than thinking "oh, they must be using PATTERN X here", think "if I were writing this code, I think PATTERN X would be appropriate". or, more usefully, "is there a pattern that solves this problem?". there isn't, necessarily
5. I am not able to understand if a statement like
Class.forName() should be viewed only in terms of a
programming instruction or
any design patternit's a line of code, nothing more. stop trying to make everything into a pattern. until you realise where patterns are and aren't applicable, you'll never understand them
6. Can "stmt.executeQuery()" can be viewed as A
Strategy Pattern? nope. what makes you think that?
I would really welcome a good discussion on the above
questions.does the discussion have to involve design patterns? you know, of course, that design patterns aren't magic beans, right? I know you've just discovered patterns, and are all excited by them, but seriously, they're only ideas, not Infallible Solutions To All Software Problems ™. the most common mistake people make using design patterns is to see them everywhere, and try to bend every problem to fit a particular pattern
for the record, nobody really views JDBC in terms of patterns. there's little value in viewing existing technologies in those terms, since the most you can "gain" is to have guessed what some other developer did, before.

Design Patterns: 'Program to an interface, not an impl.' and Factory Method

Design Patterns: 'Program to an interface, not an implementation' and Factory Method.
Hi All,
I've 4 questions. And 1M thanks for your precious input.
1. OOAD steps:
Requirement-->Use Cases-->Analysis Classes-->Sequence Diagrams-->CRC-->other UML diagrams if needed--> Domain/Business Classes.
If we follow the rule 'Program to an interface, not an implementation',
would that imply NECESSARILY we should have another set of Interface Classes for our Domain Classes? i.e Interface_ClassX for ClassX_Impl.
2. If the point 1 is a MUST because of the rule 'Program to an interface, not an implementation',
ie we should have an Interface classe for every one Domain classe,
would that NECESSARILY imply we should have as many Factory Methods as they are Domain Classes to abstract the creation process?
Interface_ClassX X= Factory.GetClassX() ( return new ClassX_Impl)
Interface_ClassY Y= Factory.GetClassY() ( return new ClassY_Impl)
Interface_ClassZ Z= Factory.GetClassZ() ( return new ClassZ_Impl)
3. On the point 2, the underlying principle used is Factory Methods.
Now on the surface, what are other possible business and/or technical naming for such Factory Methods? I mean should we call it a kind of Business Facade?
4. Is the point 1 and point 2 considered to be the best practices?

So the question here is whether we can predict having
more than one possible implementations which required
option c. Is this a dilema? I guess it's hard to
predict the future.Right. Hopefully it's fairly obvious while designing things and
deciding what objects are needed.
Now, if the Presentation Tier, says JSP, needs that
ClassNormal object. Would we still keep that line of
code a.
OR would we introduce an intermediate object to free
JSP from the direct creational aspect using new
keyword like the choice b. that you reject.
The point here is to reduce the direct coupling aspect
between the Presentation Tier and Business Tier. So
what would that intermediate object be?In that case, you have to ask yourself if there is a valid
need for reducing the coupling. If you simply make an intermediate
object, what keeps you from making an intermediate object to your
new intermediate object, ad infinitum.
That intermediate object could be a Facade pattern, or simply
an abstraction. We actually did that here, we began a massive
java project, and we abstracted away from Swing J-classes and created
our own "wrappers" that simply extended all the J-classes and we had
all our programmers develop using our wrappers instead of the Swing
classes. That allowed us to add some custom code, some temporary bug fixes, etc. Some of our classes were nothing more than "EPPasswordField extends JPasswordField" with nothing overridden. It does allow us a place to hook in and adjust or fix things if needed though.

Abstract Factory Design Pattern

Could someone please explain the abstract factory design pattern in simple english. As far as I understand it is used to create a bunch of related objects based on parameter/s provided at runtime.
However, why would one use this compared to an Interface.
I actually am reading a great book on design patterns (Design Pattern by James Cooper) but having a bit of problem really understanding this one.
Cheers

As far as I
understand it is used to create a bunch of related
objects based on parameter/s provided at runtime. There may be variations but as I understand it basically an Abstract Factory defines two interfaces, one is the factory and one is the product. A good example is iterators in Java. The iterator factory is the Iterable interface and the iterator product is the Iterator interface.
ArrayList implements Iterable so it's an iterator factory. If you call the iterator() method of an ArrayList object you'll get an Iterator object. The same applies to TreeSet and many other classes.
The Iterator objects sport the same Interface but they're quite different internally of course (Iterating an array is not the same as iterating a tree) so they're a "family of related products".

Examples of the Abstract Factory Design Pattern

Could someone please give an example about situations in which you would definitly use the Abstract Factory Design Pattern?

Ok, but they are coupled because Abstract Factory uses Factory methods. Without getting too detailed here, Abstract Factory is useful when you want to swap out entire sets of things (ie. pluggable look and feels). So one subclass of AbstractGUIFactory is MotifGUIFactory while another is WindowsGUIFactory. Your application can gets a specific factory but puts it in an AbstractFUIFactory variable.
AbstractGUIFactory factory = new WindowsGUIFactory();
AbstractButton = factory.makeButton();So you can program generically and swap out entire sets of widgets by changing one line of code.
You should really read Design Patterns by Gamma et al. because it is the definitive book on this topic.

Could someone explain the Factory Method Design Pattern

Hi Experts.
Could someone please explain for me the Factory Method Design Pattern. I read it a little and I understand that it is used in JDBC drivers but i'm not clear on it.
Could someone explain.
Thanks in advance
stephen

Basically, you have one class that's sole purpose is to create instances of a set of other classes.
What will usually happen is you have a set of related classes that inherit from some base class. We'll say for example that you have a base class CAR and it has sub-classes FORD, GM, HONDA (sorry Crylser). Instead of having the user call the constructors for FORD, GM, and HONDA, you can give the user a Factory Class that will give him a copy. We'll call our factory class Dealership. Inside dealership, you can have a static function :
public static Car makeCar(String type)
if(type.equals("FORD")
return new FORD();
else if(type.equals("GM")
return new GM();
else if(type.equals("HONDA")
return new HONDA();
So when the user needs a car, they will just call
Dealership.makeCar("FORD").
This is a good way to hide the implementation of your classes from the user, or if you require complex initialization of your objects.
Another good example of this is in the Swing library. To get a border around a component, you call static methods on BorderFactory.
Hope this helped.
Ed

[DESIGN PATTERN] Factory: Define Method Area

Hi Guys,
I have a question regarding the Design Pattern:Factory. According my need the question is below as:
I have the Abstract Class AAA with it own Abstract method that create objects (only one method).
I have a Final Sub-Class BBB with 20 instantiate methods + the inherited method from Class AAA.
BBB->method_bbb1().
BBB->method_bbb2().
BBB->method_bbb3().
I have a Final Sub-Class CCC with 10 instantiate methods + the inherited method from Class AAA.
CCC->method_ccc1().
CCC->method_ccc2().
CCC->method_ccc3().
Afterwards:
Class BBB is instantiated through the Factory. The TYPE of BBB is AAA.
Class CCC is instantiated through the Factory. The TYPE of CCC is AAA.
My question is:
How could I use the 20 methods of BBB without to declare them in AAA (without inheritance). Because, if I declare them in AAA, consequently they will be visible in CCC. And I don't want to ...
DATA BBB TYPE REF TO AAA. "Var Object BBB is type of Class AAA
DATA CCC TYPE REF TO AAA. "Var Object CCC is type of Class AAA
BBB = AAA=>Factory( 'BBB' ).
CCC = AAA=>Factory( 'CCC' ).
" I want to call, in that way:
BBB->method_bbb1().
CCC->method_ccc1().
CCC->method_bbb1(). " RAISE ERROR
I have found a way but I don't know if it's breaking the rules of the Factory Concept.
Have you got any idea?
Thank you in advance.
Rachid.

Hi,
If you have declared the methods in abstract class as protected or public and if you are inheriting it to the sub classes, then the methods will be available in the subclasses. There is no way to restrict like few abstract methods needs to be inherited and others need not be inherited. The inherited classes are forced to implement the abstract methods.
In your scenario, i do not think there is a need of abstract class, as I assume that both of your classes does some stand alone logic( as per your question ) compared to the other and doesn't have any common operations. Could you please let us know about this in detail ?? What about INTERFACES ?, Please have a look into it.
Kesav

What is command design pattern? what is the problem that it solves?

Hi i have been reading few articles on command design pattern but was unable to understand what it is and what problem does it solve. As far as my understanding goes if there is a pre specified method in an object that could execute and perform the necessary activities then it is called as command design pattern. Why is it named as command design pattern, it is because in a shell we use commands to retrieve output. For example when we type "dir" in dos command prompt it returns the list of files. so here we have to remember a preexisting exe file named "dir" which does something when used. So here like we call it command because when "dir" is passed to the computers it returns something that is expected. may be the computer obeys the command issued and return something back. So like wise if there is a method that is defined as as the command, for example in struts framework the action class must have a method "execute()" which is called by the framework to execute the necessary action mapped to it. So if there is a predefined method like "execute" in struts then the object is said to be followed command design pattern. So what actually does it solve?
What ever i have written is my understanding from the articles i have read about the design pattern. So kindly correct me if i am wrong. Help me understanding what actual problem does this pattern solves. Thanking you in advance.

This is really off-topic for these forums. You might do better on StackOverflow.com. I'll just say that although the first Design Patterns book came as a revelation to me, it was more for (a) the nomenclature (decorator, factory, facade, etc) which is still with us and (b) about five of the original patterns, which told me things I didn't already know. I've never used any of the others, including Command, and the whole design patterns thing quickly degenerated into farce with what seemed like a sustained attempt to reduce the whole of computer science to design patterns, which really isn't the point. As an example, there is one in another book called Type Object, which is nothing but 3rd normal form, which can be defined roughly in a couple of sentences. This pattern went on for dozens of pages with a very artificial example. I wrote to the mailing list about it: 'Type Object considered hilarious'. I got a rude reply from the original author, which I guess I expected, but also an incredible response from the list owner, saying I should recast my objections in the form of a design pattern. That lost it for me. True story. Moral: don't take this religion, or any IT religion, too seriously. They come around every 18 months or so with the regularity of the next bit of Moore's Law. I've seen dozens of them come and go since 1971, all with something to say, all 90% nonsense.
See here for a longer version of this incident.

EJB and Design Patterns

Hi all,
Which design patterns could be applied in coding EJB? I don't know if my question is clear enough, but what I really want to know is which design patterns I could use with EJB and how could I use them this way? (Some example situation)
Regards,
Filipe Fedalto

i think it depends of what u intend to do..
e.g. i think (maybe i'm wrong, any relevant replies are welcome!) that u could use a stateless session bean to implement some facade, delegating entities creation to some non-bean classes? or why not a stateful session bean to implement a factory (when entities creation depend on client preferences)?

Design Patterns in Dynamic Programming

I mentioned this on a thread some time ago - that many of the GoF patterns disappear in languages such as Lisp, but didn't have the reference handy. Came across it again today so I thought I'd post the link:
http://www.norvig.com/design-patterns/
Pete

hi sourdi
Below are the list of Design pattern in abap .
Singleton: ensuring single class instantiation
Adapter: making class interfaces compatible
Factory: encapsulating object creation
MVC: decoupling business logic from the view
Facade: providing a simplified interface
Composite: treating individual objects and compositions uniformly
Decorator: forming a dynamic chain of components to be used as one by the client
regards
chinnaiya P

Design Patterns in ABAP.

Hi,
I want to know about the Design Patterns in ABAP.
Regards,
Sourav

hi sourdi
Below are the list of Design pattern in abap .
Singleton: ensuring single class instantiation
Adapter: making class interfaces compatible
Factory: encapsulating object creation
MVC: decoupling business logic from the view
Facade: providing a simplified interface
Composite: treating individual objects and compositions uniformly
Decorator: forming a dynamic chain of components to be used as one by the client
regards
chinnaiya P

Factory v/s Facade Design Pattern.

Similar Messages

Maybe you are looking for