dotnet faqs: Implementing the Factory pattern -- dotnet faqs

RE: Implementing the Factory pattern

Peter Ritchie [C# MVP]
3/17/2008 11:46:03 AM

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.

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

[quoted text, click to view]

Re: Implementing the Factory pattern

Erik Cruz
3/17/2008 10:45:25 PM

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

[quoted text, click to view]

Re: Implementing the Factory pattern

sloan
3/18/2008 4:50:42 AM

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.

[quoted text, click to view]

Re: Implementing the Factory pattern

Anthony Jones
3/18/2008 5:01:23 PM

[quoted text, click to view]

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.

--
Anthony Jones - MVP ASP/ASP.NET

Re: Implementing the Factory pattern

Erik Cruz
3/18/2008 11:32:49 PM

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

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the dotnet faqs group.