Design Pattern - Abstract Factory

[max]

Hello,

I analyze this design pattern for a long time but I do not understand how
this pattern work and what the purpose is? (I looked a this site
http://www.dofactory.com/Patterns/PatternAbstract.aspx).

Could anybody try to explain me in his own words how this pattern work and
what the purpose is?

thanks in advance

max

PS: Generally I do not understand why they use (also in Adapter) for example
AbstractFactory factory1 = new ConcreteFactory1(); - Means they define a
object from an abstract class and create in this object a object from a
concrete class. What is the sense of that? :(

[Olaf Baeyens]

> PS: Generally I do not understand why they use (also in Adapter) for
example

AbstractFactory factory1 = new ConcreteFactory1(); - Means they define a
object from an abstract class and create in this object a object from a
concrete class. What is the sense of that? :(

See it as a form of typecasting.

Suppose you create spin-off classes from the AbstractFactory through
inheritance, for example ConcreteFactory1, ConcreteFactory2,
ConcreteFactory3. This way you could hook any inherited of them to this one
variable.

Now imagine that the abstract class have a public Print() method and the you
override that print in the inhertied spin-offs.

Thsi way you could call factory1.Print() and depending if you hooked
ConcreteFactory1, ConcreteFactory2 or ConcreteFactory3 to it, you will call
the custom Print ConcreteFactory1.Print(), ConcreteFactory2.Print() or
ConcreteFactory3 .Print().

For example:
AbstractFactory factory1 = new ConcreteFactory1();
factory1.Print() actually calls ConcreteFactory1.Print()

but if you would have done this;
AbstractFactory factory1 = new ConcreteFactory2();
then factory1.Print() actually calls ConcreteFactory2 .Print()

In this case we could have created ConcreteFactory1 factory1 = new
ConcreteFactory1() and it would work too if ony ConcreteFactory1 is supposed
to be used, but imagin that if you create a list of items that could be
ConcreteFactory1, ConcreteFactory2 or ConcreteFactory3 then making it
AbstractFactory factory1 = new ConcreteFactory1(); is more usefull
especially in this case:

(suppose list is an array of AbstractFactory)

for (int i=0; ix<iCount; i++) {
List[i].Print();
}

Basically it is a technique to make your code simpler, readable and reusable
and is regularly used in OOP programming

I hope this helps?

[max]

Hello,

thank you very much for this information, now I understand the intentions
behind this statement.
Could you further explain me how this Abstract Factory work and what the
intention is behind the AbstractFactory? Unfurtunately I do not look through
it related to the UML Diagram and the explanation on my previos posted link.
:((

regards

max

"Olaf Baeyens" wrote:

PS: Generally I do not understand why they use (also in Adapter) for

example

AbstractFactory factory1 = new ConcreteFactory1(); - Means they define a
object from an abstract class and create in this object a object from a
concrete class. What is the sense of that? :(

See it as a form of typecasting.

Suppose you create spin-off classes from the AbstractFactory through
inheritance, for example ConcreteFactory1, ConcreteFactory2,
ConcreteFactory3. This way you could hook any inherited of them to this one
variable.

Now imagine that the abstract class have a public Print() method and the you
override that print in the inhertied spin-offs.

Thsi way you could call factory1.Print() and depending if you hooked
ConcreteFactory1, ConcreteFactory2 or ConcreteFactory3 to it, you will call
the custom Print ConcreteFactory1.Print(), ConcreteFactory2.Print() or
ConcreteFactory3 .Print().

For example:
AbstractFactory factory1 = new ConcreteFactory1();
factory1.Print() actually calls ConcreteFactory1.Print()

but if you would have done this;
AbstractFactory factory1 = new ConcreteFactory2();
then factory1.Print() actually calls ConcreteFactory2 .Print()

In this case we could have created ConcreteFactory1 factory1 = new
ConcreteFactory1() and it would work too if ony ConcreteFactory1 is supposed
to be used, but imagin that if you create a list of items that could be
ConcreteFactory1, ConcreteFactory2 or ConcreteFactory3 then making it
AbstractFactory factory1 = new ConcreteFactory1(); is more usefull
especially in this case:

(suppose list is an array of AbstractFactory)

for (int i=0; ix<iCount; i++) {
List[i].Print();
}

Basically it is a technique to make your code simpler, readable and reusable
and is regularly used in OOP programming

I hope this helps?

[Nick Malik [Microsoft]]

"max" <ma*@discussions.microsoft.com> wrote in message
news:1D**********************************@microsof t.com...

Hello,

I analyze this design pattern for a long time but I do not understand how
this pattern work and what the purpose is? (I looked a this site
http://www.dofactory.com/Patterns/PatternAbstract.aspx).

Could anybody try to explain me in his own words how this pattern work and
what the purpose is?

thanks in advance

max

PS: Generally I do not understand why they use (also in Adapter) for
example
AbstractFactory factory1 = new ConcreteFactory1(); - Means they define a
object from an abstract class and create in this object a object from a
concrete class. What is the sense of that? :(

First of all, the creational patterns attempt to seperate creation of an
object from its use. This ties to the notion that the 'new' keyword, when
used in a procedure that both creates and object and uses it, is harmful,
because it cannot be subclassed. 'new' always creates a concrete object and
always an object of the type specifically mentioned in the code. This is
not always appropriate. Sometimes, you want the system to have
configuration files that declare which type of a 'animal' class to create
and the calling code doesn't care if the actual object created is a 'dog' or
a 'horse'.

That is the basic foundation behind the factory patterns. The two most
common are factory method and abstract factory. Factory method just allows
an object of Type T to be created by a bit of code, and that code can have
all the logic needed to build Type T (or any if its descendents) without the
calling class being aware of which concrete object is created.

Sometimes the factory method is done by creating a single method on an
object that is otherwise part of the same heirarchy as the object it
creates. More frequently, you will have special factory object that
contains only one method, just to create the child object. Note: this is
massive overkill for situations where a descendent will never be created and
should be avoided unless you can justify it. Otherwise, your code can get
difficult to maintain.

Abstract Factory is a special case of Factory method. It is used primarily
in frameworks when you have RELATED objects. For example, let's say that
you have a system whereby your entire business object layer is nicely
isolated from the user interface. You want to run automated tests on your
user interface, but you don't want those automated tests to fail if there is
a defect in the business object layer. In other words, automated UNIT
testing. You could have a single concrete object that creates each of the
objects in the business layer. Let's say it is of Type ActualFactory. If
ActualFactory inherits from AbstractFactory interface, then you could also
have an object called MockFactory that, instead of creating the actual
business objects, creates "mock" objects... simple objects with very few
side effects that respond with minimal logic in an expected way for the sake
of testing.

So, in the real system, you would create an ActualFactory object and then
use it to create each of your business objects. In the Testing scenario,
you would create a MockFactory object instead. If the calling code used the
AbstractFactory interface that they both inherit from, then the calling code
is completely unaware if it is performing actual logic or if it is simply
being tested. This is the best way to test... where the code cannot tell if
it is being tested.

I hope this helps.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

[Olaf Baeyens]

> thank you very much for this information, now I understand the intentions

behind this statement.
Could you further explain me how this Abstract Factory work and what the
intention is behind the AbstractFactory? Unfurtunately I do not look through it related to the UML Diagram and the explanation on my previos posted link. :((

The most simplest way to describe what it is doing is that this factory
class is some kind of shortcut that creates another type of object(s).
So you could have a list of different types of shortcuts (factories
instantiated as object) that creates other objects.