Return to Answer

The factory pattern is a Creational pattern. It can be used to build objects of a particular base type with out specifying the exact concrete type, this is determined by any input and the create logic inside the factory.

public class VehicleFactory { public IVehicle Create(int noOfWheels) { if (noOfWheels == 1) return new UniCycle(); if (noOfWheels == 2) return new MotorCycle(); if (noOfWheels == 3) return new Trike(); if (noOfWheels == 4) return new Car(); throw new NotImplementedException(); } } public class UniCycle : IVehcicle { ... } public class MotorCycle: IVehcicle { ... } public class Trike: IVehcicle { ... } public class Car: IVehcicle { ... } 

The following is a simple C# example using your vehicle idea as the basis. The usefulness is that any consuming code doesn't care what the concrete class is just that it gets back an IVehicle. It doesn't have to be done with interfaces either, all though I prefer them, it could also be done with an abstract base class depending on the situation.

When I use the factory pattern I normally have the factory implement an interface, this is called the Abstract Factory Pattern. For this example it would be something like:

public interface IVehicleFactory { IVehicle Create(int noOfWheels); } 

The factory can then be injected into classes (see IoC). This allows you to decouple your code. It makes the consuming code cleaner, all it has to do is pass a value, if required, to the factory and it will be given back a product that conforms to an interface. With this level of abstraction and code separation unit testing becomes a lot easier.

The wiki link I have provided for the Abstract Factory Pattern has some examples in Python.

The factory method pattern is a Creational pattern. It can be used to build objects of a particular base type with out specifying the exact concrete type, this is determined by any input and the create logic inside the factory.

public class VehicleFactory { public IVehicle Create(int noOfWheels) { if (noOfWheels == 1) return new UniCycle(); if (noOfWheels == 2) return new MotorCycle(); if (noOfWheels == 3) return new Trike(); if (noOfWheels == 4) return new Car(); throw new NotImplementedException(); } } public class UniCycle : IVehcicle { ... } public class MotorCycle: IVehcicle { ... } public class Trike: IVehcicle { ... } public class Car: IVehcicle { ... } 

The following is a simple C# example using your vehicle idea as the basis. The usefulness is that any consuming code doesn't care what the concrete class is just that it gets back an IVehicle. It doesn't have to be done with interfaces either, all though I prefer them, it could also be done with an abstract base class depending on the situation.

When I use the factory pattern I normally have the factory implement an interface, this is called the Abstract Factory Pattern. For this example it would be something like:

public interface IVehicleFactory { IVehicle Create(int noOfWheels); } 

The factory can then be injected into classes (see IoC). All together it gives you:

• Decouple your code.
• Allows for different implementations of a factory.
• Consuming code cleaner, no object instantiation.
• Unit testing is easier, fewer complex concrete classes to worry about.

The wiki link I have provided for the Abstract Factory Pattern has some examples in Python.

The factory pattern is a Creational pattern. It can be used to build objects of a particular base type with out specifying the exact concrete type, this is determined by any input and the create logic inside the factory.

public class VehicleFactory { public IVehicle Create(int noOfWheels) { if (noOfWheels == 1) return new UniCycle(); if (noOfWheels == 2) return new MotorCycle(); if (noOfWheels == 3) return new Trike(); if (noOfWheels == 4) return new Car(); throw new NotImplementedException(); } } public class UniCycle : IVehcicle { ... } public class MotorCycle: IVehcicle { ... } public class Trike: IVehcicle { ... } public class Car: IVehcicle { ... } 

The following is a simple C# example using your vehicle idea as the basis. The usefulness is that any consuming code doesn't care what the concrete class is just that it gets back an IVehicle. It doesn't have to be done with interfaces either, all though I prefer them, it could also be done with an abstract base class depending on the situation.

When I use the factory pattern I normally have the factory implement an interface. For this example it would be something like:

public interface IVehicleFactory { IVehicle Create(int noOfWheels); } 

The factory can then be injected into classes (see IoC). This allows you to decouple your code. It makes the consuming code cleaner, all it has to do is pass a value, if required, to the factory and it will be given back a product that conforms to an interface. With this level of abstraction and code separation unit testing becomes a lot easier.

The factory pattern is a Creational pattern. It can be used to build objects of a particular base type with out specifying the exact concrete type, this is determined by any input and the create logic inside the factory.

public class VehicleFactory { public IVehicle Create(int noOfWheels) { if (noOfWheels == 1) return new UniCycle(); if (noOfWheels == 2) return new MotorCycle(); if (noOfWheels == 3) return new Trike(); if (noOfWheels == 4) return new Car(); throw new NotImplementedException(); } } public class UniCycle : IVehcicle { ... } public class MotorCycle: IVehcicle { ... } public class Trike: IVehcicle { ... } public class Car: IVehcicle { ... } 

The following is a simple C# example using your vehicle idea as the basis. The usefulness is that any consuming code doesn't care what the concrete class is just that it gets back an IVehicle. It doesn't have to be done with interfaces either, all though I prefer them, it could also be done with an abstract base class depending on the situation.

When I use the factory pattern I normally have the factory implement an interface, this is called the Abstract Factory Pattern. For this example it would be something like:

public interface IVehicleFactory { IVehicle Create(int noOfWheels); } 

The factory can then be injected into classes (see IoC). This allows you to decouple your code. It makes the consuming code cleaner, all it has to do is pass a value, if required, to the factory and it will be given back a product that conforms to an interface. With this level of abstraction and code separation unit testing becomes a lot easier.

The wiki link I have provided for the Abstract Factory Pattern has some examples in Python.

The factory pattern is a Creational pattern. It can be used to build objects of a particular base type with out specifying the exact concrete type, this is determined by any input and the the create logic.

public class VehicleFactory { public IVehicle Create(int noOfWheels) { if (noOfWheels == 1) return new UniCycle(); if (noOfWheels == 2) return new MotorCycle(); if (noOfWheels == 3) return new Trike(); if (noOfWheels == 4) return new Car(); throw new NotImplementedException(); } } public class UniCycle : IVehcicle { ... } public class MotorCycle: IVehcicle { ... } public class Trike: IVehcicle { ... } public class Car: IVehcicle { ... } 

The following is a simple C# example using your vehicle idea as the basis. The VehicleFactory could implement an IVehicleFactory interface, this would be useful if you were doing IoC. The usefulness is that any consuming code doesn't care what the concrete class is just that it gets back an IVehicle. It doesn't have to be done with interfaces either, all though I prefer them, it could also be done with an abstract base class depending on the situation.

The factory pattern is a Creational pattern. It can be used to build objects of a particular base type with out specifying the exact concrete type, this is determined by any input and the create logic inside the factory.

public class VehicleFactory { public IVehicle Create(int noOfWheels) { if (noOfWheels == 1) return new UniCycle(); if (noOfWheels == 2) return new MotorCycle(); if (noOfWheels == 3) return new Trike(); if (noOfWheels == 4) return new Car(); throw new NotImplementedException(); } } public class UniCycle : IVehcicle { ... } public class MotorCycle: IVehcicle { ... } public class Trike: IVehcicle { ... } public class Car: IVehcicle { ... } 

The following is a simple C# example using your vehicle idea as the basis. The usefulness is that any consuming code doesn't care what the concrete class is just that it gets back an IVehicle. It doesn't have to be done with interfaces either, all though I prefer them, it could also be done with an abstract base class depending on the situation.

When I use the factory pattern I normally have the factory implement an interface. For this example it would be something like:

public interface IVehicleFactory { IVehicle Create(int noOfWheels); } 

The factory can then be injected into classes (see IoC). This allows you to decouple your code. It makes the consuming code cleaner, all it has to do is pass a value, if required, to the factory and it will be given back a product that conforms to an interface. With this level of abstraction and code separation unit testing becomes a lot easier.