—factory and abstract factory pattern in .net———-
Note: – This is quiet a confusing architect question especially in design pattern section.
Interviewer can take you for a nice ride. So get the difference in your heart.
First read the definition provided in the first question about both these patterns. The common thing they have is that they belong to creational patterns. In short they hide the complexity of creating objects.
The main difference between factory and Abstract factory is factory method uses
inheritance to decide which object has to be instantiated while abstract factory uses
delegation to decide instantiation of object. We can say Abstract factory uses factory
259 method to complete the architecture. Abstract Factory is one level higher in abstraction over Factory.
First figure shows a sample implementation of Factory Patterns. In this figure there are
two basic sections:-
√ The actual product section i.e. Class “Product” it inherits from an abstract
class “AbstractProduct”.
√ The creational aspect section i.e. “ConcreteCreator” class which inherits
from class “Creator”.
√ Now there are some rules the client will have to follow who
will need the “Product” object. He will never refer directly to the actual “Product” object
he will refer the “Product” object using “AbstractProduct”.
√ Second client will never use “New” keyword to create the “Product” object
but will use the “Creator” class which in turn will use the “ConcreteCreator”
class to create the actual “Product” object.
So what are the benefits from this architecture? All creational and initializing aspects are
now detached from the actual client. As your creational aspect is now been handled in
“ConcreteCreator” and the client has reference to only “Creator”, so any implementation
change in “CreateProduct” will not affect the client code. In short now your creational
aspect of object is completely encapsulated from the client’s logic.
260
Now let’s look at the second class diagram which provides an overview of what actually
“Abstract factory” pattern is. It creates objects for families of classes. In short it describes
collection of factor methods from various different families. In short it groups related
factory methods. Example in this the class “Creator” is implemented using the “Abstract”
factory pattern. It now creates objects from multiple families rather one product.
Note :- Just stick up to this definition that Abstract factory classifies factory methods or
groups logically related factory method together.
How Singleton is different from Static class?
- Singleton is a design pattern which solves the problem in a particular context (when we want that only one instance of an object can be created). Whereas static class is a concept where class will be defined with static keyword and all the members need to be strictly static
- Singleton pattern let us create the object of the class only once whereas we can’t create the object of static class.
- Class which follows singleton pattern can implement other interfaces whereas static class cannot.
There is one more question normally asked during interviews “What you will prefer for sharing, static class or singleton pattern”
First of all both allows us to share, but I personally prefer singleton pattern because we can derive our singleton class from other interfaces and so get polymorphic feature.
Example: IPerson s=SingletonPerson.GetObject(PersonEnum.Male); //s is Male
: IPerson s=SingletonPerson.GetObject(PersonEnum.Female); //s is Female
Secondly Singleton class may contain some non-static members as well.
And most importantly we can control the life of a singleton object. It can be explicitly destroyed in between the application.
in pizza example if NYstore act as client
then it get productA, produtB etc from factory
and can directly access.
but if we treat NYStore as pizzachef
(as suggested by tcarvin ) and client accces it
to get complete pizza it act as builder
(pizzache as directore and ingredient class as builder)
Following image can exact tell what is the exact difference
note : i am putting this image so whoever visit
this post can understand easily.
NOW I AM HUNGRY also.
Common steps is implemented in Builder
Protected constructor
It is possible to use a protected constructor to in order to permit the subclassing of the singeton. This techique has 2 drawbacks that makes singleton inheritance impractical:
- First of all, if the constructor is protected, it means that the class can be instantiated by calling the constructor from another class in the same package. A possible solution to avoid it is to create a separate package for the singleton.
- Second of all, in order to use the derived class all the getInstance calls should be changed in the existing code from Singleton.getInstance() to NewSingleton.getInstance().
Multiple singleton instances if classes loaded by different classloaders access a singleton.
If a class(same name, same package) is loaded by 2 diferent classloaders they represents 2 different clasess in memory.