Is it possible combine the Abstract factory pattern and singleton pattern together?if yes then,how?give me some example with diagram .
The abstract factory pattern is all about creating objects. The singleton pattern is all about not creating more than one object of a particular type. How and why do you envisage them working together?
Related
From GOF book:
Class patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance,
so they are static-fixed at compile-time. Object patterns deal
with object relationships, which can be changed at run-time and
are more dynamic. Almost all patterns use inheritance to some extent.
So the only patterns labeled "class patterns" are those that focus on
class relationships.
Why is factory method a class pattern, and abstract factory an object pattern, given that they seem to be very similar patterns?
Thanks.
Factory Method and Abstract Factory are similar in intent, but wildly different in implementation (you might even say opposite). In other words, these patterns represent different ways of solving the same problem (instantiation).
The GoF says,
We classify design patterns by two criteria. The first criterion,
called purpose, reflects what a pattern does.
Because their intent is similar (i.e. they have the same purpose) these two patterns are both classified as creational.
The GoF goes on to say,
The second criterion, called scope, specifies whether the pattern applies
primarily to classes or to objects.
This leads into the quote from the OP, where class and object scope are each defined. Because Factory Method's implementation focuses on inheritance (a class relationship) while Abstract Factory's implementation focuses on composition (an object relationship) these two patterns are classified under opposing scopes.
The definitions and implementations of these two patterns can be found in numerous other SO threads, so I will not repeat them here. I have also touched on the composition vs. inheritance question in these two patterns elsewhere.
The GOF book says
Intent
Define an interface for creating an object, but let subclasses decide which class to instantiate.
What does this mean? Let's take a look at the example that the book shows.
In the example a framework defines the Application interface to let others implement it. This means that I can implement e.g. a MyApplication or MyOtherApplication like this:
public class MyApplication extends Application {
protected Document createDocument() {
return new MyDocument();
}
}
public class MyOtherApplication extends Application {
protected Document createDocument() {
return new MyOtherDocument();
}
}
When the framework starts it might choose one of these implementations depending on what it finds on the classpath.
But it means that after the framework has instantiated either MyApplication or MyOtherApplication the way a document is created is fix. The way a document is created can not be changed anymore at runtime for the Application instance. There is no setter or anything else that you can use to change the way the Document is created. Thus it is also called a virtual constructor and thus it is a class pattern.
Abstract Factory
In contrast to the factory method an abstract factory can be changed at runtime and thus the way the objects it creates. That's why they say it is an object pattern.
A abstract factory is also responsible for creating
... families of related or dependent objects ...
This is also a difference to the factory method aka. virtual constructor.
Factory patterns are probably better to place in its own category. But logic behind object/class division maybe quite simple. Factory method in its minimal form is static (not configurable), just like classes are. But abstract factory result (object they produce) class depends on some input data, and since it is dynamic effect it should be put into object pattern category.
I have an object that I would like to create. This object is composed of other objects that I don't want the client class to be responsible for creating. There are lots of validation rules that must pass before the object can be created.
So I would like to abstract away the creation of this complex object into a "factory" class. I have 2 questions really, the first is purely about semantics:-
What should I call the class which is creating my object? The factory method pattern and abstract factory pattern are both related to abstracting away creation of concrete classes of different types. However, I'm creating an object of a single type, so using the term factory might be confusing?
Is this an appropriate solution? Are there any patterns/examples of this being done?
Thanks in advance for any help/guidance.
You can use the term factory because we all use it in its broadest sense unless we use a more unique name like Factory Method design pattern or Abstract Factory design pattern.
Builder pattern is typically used if you have an object build process that should still be used if the same master steps should be used in creating different types of objects. But in your case you just have one type. So there's no need for a better solution since there's no special problem to solve. Just do the validation in the simplest form you can.
Hi there I hope I am able to explain myself clear enough with this problem I have been really confused about.
I have a concrete class called UTModule, it is not subclassed at all, but it is composed of several different abstract objects (for example UTListener, UTRenderer, UTDeliverer) the instantiation of these abstract classes to concrete objects defines the behaviour of my completed UTModule object.
The question I am asking is that, every example I see for the factory design pattern is in regards to an abstract object that is subclassed, whereas my object is a concrete class who's behaviour is decided by its composition.
Am I supposed to create a factory for each of my composite abstract objects? Or just create one factory that creates my UTModule, with the correct composite objects depending on the clients request?
Thanks in advance!
I feel like using the Abstract factory pattern is a clear solution for you.
Lets take UTModule as a abstract factory class which has methods to create a Factory of the Other Objects like "UTListener, UTRenderer, UTDeliverer"
Some additional interface is required for each UTListener, UTRenderer, UTDeliverer and respective factory class for each family.
UTModule add all require method to return the factory of the family you are looking.
For More details and example please follow OODesgin
Is there a similar pattern in objective-c to create an observer pattern as there is in Java?
That way the attributes of a super class will pass inheritance to subclasses.
I'm working on an application with many inheritance hierarchies that are not directly related.
Do I have to assign a factory method for each hierarchy in the client code to select a certain class from each hierarchy to instantiate upon the user selection through the GUI?
Instead if a concret Factory you may take a look at the Abstract Factory
Abstract Factory offers the interface for creating a family of related objects, without explicitly specifying their classes.
Reference
If objects are not related, I think you can't avoid having a factory for each object. Take a look at the Dependency Injection architecture , it could be an interesting option Dependency Injection vs Factory Pattern
Have a look at this webpage, which demonstrates using the Abstract Factory pattern with multiple inheritance hierarchies: http://www.dofactory.com/Patterns/PatternAbstract.aspx.