MSDN Factory article related question

[BigStef]

Hi everybody,
I was reading this article on MSDN: http://msdn.microsoft.com/en-us/library/ms954600.aspx
and I was wondering about the implementation explained in this article
about passing a factory instance from the main class to the class that
calls the factory methods. I'm puzzled about the approach explained
there.

Here's a bit of what is explained in this article and what approach I
was used to take:


MSDN's:

class ComputerAssembler {

public void AssembleComputer(ComputerFactory factory) { //
<---------------------- Receives the factory instance

Computer computer = factory.GetComputer();
Console.WriteLine("assembled a {0} running at {1} MHz",
computer.GetType().FullName, computer.Mhz);

}//AssembleComputer

}//ComputerAssembler

class MainClass {

static void Main(string[] args) {

ComputerFactory factory = new ConcreteComputerFactory(); //
<----------- Creates an instance of the factory to use...

new ComputerAssembler().AssembleComputer(factory); //Passing the
instance to a method

}//Main

}//MainClass


My approach:
class ComputerAssembler {
private static ComputerFactory factory = new
ConcreteComputerFactory(); //<----------- Creates an instance of the
factory to use
public void AssembleComputer() {

Computer computer = factory.GetComputer();
Console.WriteLine("assembled a {0} running at {1} MHz",
computer.GetType().FullName, computer.Mhz);

}//AssembleComputer

}//ComputerAssembler

class MainClass {

static void Main(string[] args) {

new ComputerAssembler().AssembleComputer(); //Not passing any
factory instance since it's encapsulated within the ComputerAssembler
class

}//Main

}//MainClass

As you can see, the client doesn't have to know that a factory is
involved in the creation of a specific object. It just calls whatever
the method needed to.
One discussion I had with another developper is the fact that the
MSDN's example is also extending this sample a bit further by reading
command line args that might have been passed to instanciate the
appropriate factory then pass it from the main class. This can be
easilly done by using generics. I was just wondering if there were any
benefits from doing this that way.

Thanks,

Steph

 

[Jon Skeet [C# MVP]]

As you can see, the client doesn't have to know that a factory is
involved in the creation of a specific object. It just calls whatever
the method needed to.
One discussion I had with another developper is the fact that the
MSDN's example is also extending this sample a bit further by reading
command line args that might have been passed to instanciate the
appropriate factory then pass it from the main class. This can be
easilly done by using generics. I was just wondering if there were any
benefits from doing this that way.

Your approach tightly couples ComputerAssembler to
ConcreteComputerFactory. In particular, you can't test
ComputerAssembler without ConcreteComputerFactory getting involved -
and that will presumably return a ConcreteComputer as well. If you
couple everything through interfaces and use dependency injection, you
can genuinely test units of functionality.

Jon

 

[BigStef]

Your approach tightly couples ComputerAssembler to
ConcreteComputerFactory. In particular, you can't test
ComputerAssembler without ConcreteComputerFactory getting involved -
and that will presumably return a ConcreteComputer as well. If you
couple everything through interfaces and use dependency injection, you
can genuinely test units of functionality.

Jon

I see. But suppose the factory becomes huge, heavy and complex, isn't
it a bit heavy on performances? I always try to keep a balance between
performance and "purist" ways of doing things. Though, I agree that
tightly coupling classes isn't a good design practice in general.

 

[Jon Skeet [C# MVP]]

I see. But suppose the factory becomes huge, heavy and complex, isn't
it a bit heavy on performances?

Which part would you expect to become heavy in terms of performance?
If it becomes complex, that complexity would have to be *somewhere*
anyway - and it's a lot easier to split up the complexity when you're
using dependency injection. You can split a class up into several
roles by making it implement several interfaces, then just use those
interfaces in the calling code, and then split the class itself into
multiple classes each of which implements a single interface.

I always try to keep a balance between
performance and "purist" ways of doing things. Though, I agree that
tightly coupling classes isn't a good design practice in general.

When you're trying to keep a balance, do you *measure* the
performance? If not, you have no idea where the balance actually is.
In this case I really can't see how it would impact performance at
all.

Jon

 

[sloan]

To me that an advantage of the Factory Pattern.

To isolate the logic of how/which concretes to build up. Instead of
scattering it.

I use the Simple Factory alot more than the Abstract Factory, however, the
code in the Factory(ies) usually seems intuitive to me.

...

I see. But suppose the factory becomes huge, heavy and complex, isn't
it a bit heavy on performances?

Which part would you expect to become heavy in terms of performance?
If it becomes complex, that complexity would have to be *somewhere*
anyway - and it's a lot easier to split up the complexity when you're
using dependency injection. You can split a class up into several
roles by making it implement several interfaces, then just use those
interfaces in the calling code, and then split the class itself into
multiple classes each of which implements a single interface.

I always try to keep a balance between
performance and "purist" ways of doing things. Though, I agree that
tightly coupling classes isn't a good design practice in general.

When you're trying to keep a balance, do you *measure* the
performance? If not, you have no idea where the balance actually is.
In this case I really can't see how it would impact performance at
all.

Jon