If I use an abstract class instead of an interface when implementing a factory template. Will there be another factory template?

Question

For example: http://www.tutorialspoint.com/design_pattern/factory_pattern.htm

If I changed the form of the interface in the abstract Shape class, make specific classes to extend the form and make the factory form return objects of the abstract Shape class. Will it still be a factory template?

Answer 1

I would go with yes.

Let's look at the definition of the Factory method template:

The Factory method template is a creational template that uses Factory methods to solve the problem of creating objects without specifying the exact class of the object to be created.

The motivation for this template is to separate the creation of the object from the client using the object. The client must provide the Factory specification, but the details of how the object is constructed are abstracted from the factory.

If it is an interface or an abstract class, this is a situation-specific implementation detail if your Factory implementation allows you to achieve motivation for the template.

Consider using abstract classes if any of these statements apply to your situation:

• You want to share the code between several related classes.

• You expect classes that extend your abstract class to have many common methods or fields, or require access modifiers other than public ones (like protected and private).

• You want to declare non-static or non-final fields. This allows you to define methods that can access and change the state of the object to which they belong.

Consider using interfaces if any of these statements apply to your situation:

• You expect unrelated classes to implement your interface. For example, the Comparable and Cloneable interfaces are implemented by many unrelated classes.

• You want to specify the behavior of a particular data type, but are not concerned about who implements its behavior.

• You want to use multiple type inheritance.

In some implementations, it may even make sense to use an abstract class rather than an interface for products created by the factory. If there is a common set of functions / behavior between all products, then it makes sense to include them in the base abstract class. This can be applied even if the products are built in different factories.

It comes down to: do you want, and does it make sense to introduce a clutch between products or not? As a result, the client will receive the same result - the product is built on the basis of the specification, the details are abstracted.

Answer 2

When it comes to this kind of difference, the answer can always be yes or no. Design patterns are not a specific specification, they are more like a set of best and recommended practices, and their implementation varies from case to case.

In my opinion, the answer is no, technically it will not be a factory pattern. And this is not necessary as long as it solves your use case and makes the code readable and maintainable (trying to literally stick to design patterns often leads to their misuse and excessive architecture).

If we look at the Abstract factory template (right below the factory template on the linked page), we will see that it is a factory for creating factories. Suppose now that we have two Shape factories that AbstractFactory can create: ShapeFactory2D and ShapeFactory3D , producing Shape objects.

If Shape was an abstract class, then you would force both 2D and 3D objects to inherit the same implementation, although this may not make sense (they can be implemented in completely different ways).

So, technically, in order for this to really be a factory pattern, there should be no assumptions about implementation details, that is, abstract classes containing a partial implementation should not be used at the factory interface level.

Of course, you can have Abstract2DShape and Abstract3DShape abstract classes that implement Shape ; The fact is, you can create and use a Shape without knowing whether it is a 2D or 3D shape.