Implementing the Factory pattern

[Erik Cruz]

Hi.

I don't know if it is a FAQ, but I am reading about the Factory pattern on
MSDN. I understand the concepts and the structure of the files involved. But
when it comes to .NET, how do I implement this pattern? In order to achieve
real abstraction do I need to create separate projects for my client
application, my factory class and my implementation class?

Thanks !!

Erik

 

[Peter Ritchie [C# MVP]]

The factory pattern is a form of dependency inversion. This means you're
attempting to keep something from depending directly on something else.
There's various levels at which this can happen. The simplest is simply one
class doesn't depend on another and is used indirectly via an interface
(trading one dependency for another), which is a class-level abstraction. If
that's all you need, you're done. You can extend this dependency inversion
down to other levels by putting the interface and the other class in two
separate projects and you thus have a module-level abstraction. the benefit
of this level of abstraction is that one class is truly independent of the
other, you're free to deploy each independently and changes to one don't leak
to the other (where class-level abstraction would require the assembly in
which both classes reside to be re-deployed should only one be changed).

Maybe if you detail some of your reasons for using the factory pattern we
can offer some more detailed recommendations.

 

[Erik Cruz]

Hi Peter.

I am designing an utilities class that will be used by all the developers of
my team. I made a single project with 3 .vb files, one for the Interface,
other for a class factory and another one for the implementation class.

Interface IUtils
Function SaveFile(path As string) As Boolean
End Interface

Public Class UtilsFactory
Public Function CreateInstance As IUtils
Return Utils.Instance
End Function
End Class

'That's my implementation class
Public Class Utils
Implements IUtils

Public Shared Function Instance() As Utils
Return New Utils
End Function
End Class

The way I see it, if I change something on my Interface I should change the
implementation class also, because of this I have defined all the files on
the same project. Is this correct?

Thanks !!

Erik

 

[sloan]

Understanding the simple factory pattern
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!126.entry


If you change something on your interface, you'll be forced to change that
something on your single (or multiple) concrete classes.


check www.dofactory.com as well for their list of free design patterns.
they have an example as well.

if you are interested in a book the Head First Design Patterns book is a
good investment.

 

[Anthony Jones]

Hi Peter.

I am designing an utilities class that will be used by all the developers of
my team. I made a single project with 3 .vb files, one for the Interface,
other for a class factory and another one for the implementation class.

Interface IUtils
Function SaveFile(path As string) As Boolean
End Interface

Public Class UtilsFactory
Public Function CreateInstance As IUtils
Return Utils.Instance
End Function
End Class

'That's my implementation class
Public Class Utils
Implements IUtils

Public Shared Function Instance() As Utils
Return New Utils
End Function
End Class

The way I see it, if I change something on my Interface I should change the
implementation class also, because of this I have defined all the files on
the same project. Is this correct?

Its not clear why the factory pattern is needed here?

Do anticipate the need for other implementations of the IUtils interface?

If so should not CreateInstance take a parameter so it can differentiate
which instance it should return?

I suspect all you really need is Utils class with a set of Shared methods.
There is no need for factory here and I'd think twice about even using an
interface in this case.

 

[Erik Cruz]

Hi Anthony.

Maybe I am failing to see when to adopt the pattern, since I am trying to
start creating a framework for my company. I am thinking of decoupling, but
maybe an utilities class is not a good example.

Do you know of any article that can clarify when to use this pattern and
when not to use it? I will look at the books mentioned in this thread also.

Thanks,

Erik