![]() |
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
| Welcome to Windows Vista Forums. Our forum is dedicated to helping you find solutions with any problems, errors or issues you are experiencing with Windows Vista. The Vista forum also covers news and updates and has an extensive Windows Vista tutorial section that covers a wide range of tips and tricks. |
| |||||||
![]() |
| |
| | #1 (permalink) |
| | Implementing the Factory pattern 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 |
My System Specs![]() |
| | #2 (permalink) |
| | RE: Implementing the Factory pattern 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# "Erik Cruz" wrote: Quote: > 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 > > > |
My System Specs![]() |
| | #3 (permalink) |
| | Re: Implementing the Factory pattern 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 "Peter Ritchie [C# MVP]" <PRSoCo@xxxxxx> wrote in message news:11D14017-AA96-495C-8B4F-1495DD75699D@xxxxxx Quote: > 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# > > > "Erik Cruz" wrote: > Quote: >> 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 >> >> >> |
My System Specs![]() |
| | #4 (permalink) |
| | Re: Implementing the Factory pattern Understanding the simple factory pattern http://sholliday.spaces.live.com/Blo...842A!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. "Erik Cruz" <erikacf@xxxxxx> wrote in message news:%23fcps8xhIHA.536@xxxxxx Quote: > 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 > |
My System Specs![]() |
| | #5 (permalink) |
| | Re: Implementing the Factory pattern "Erik Cruz" <erikacf@xxxxxx> wrote in message news:ODhEbnJiIHA.6084@xxxxxx Quote: > Hi Peter. > > I am designing an utilities class that will be used by all the developers Quote: > 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 Quote: > 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. -- Anthony Jones - MVP ASP/ASP.NET |
My System Specs![]() |
| | #6 (permalink) |
| | Re: Implementing the Factory pattern 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 "Anthony Jones" <Ant@xxxxxx> wrote in message news:uxjPzmRiIHA.5088@xxxxxx Quote: > "Erik Cruz" <erikacf@xxxxxx> wrote in message > news:ODhEbnJiIHA.6084@xxxxxx Quote: >> Hi Peter. >> >> I am designing an utilities class that will be used by all the developers Quote: >> 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 Quote: >> 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. > > > > -- > Anthony Jones - MVP ASP/ASP.NET > > |
My System Specs![]() |
![]() |
| Thread Tools | |
| |
Similar Threads | ||||
| Thread | Forum | |||
| implementing get-item | PowerShell | |||
| Implementing Unmanaged Interface in C# | .NET General | |||
| Implementing SMO using Powershell (Part 2) | PowerShell | |||
| Implementing SMO in Powershell | PowerShell | |||
| implementing security templates | Vista security | |||