13

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

If I change interface shape on abstract class Shape, make concrete classes to extend Shape and Make the Shape factory return Shape abstract class typed objects. Is it still going to be a factory pattern ?

Achozen
  • 161
  • 1
  • 9
  • 1
    Short answer: Yes. Actually, since Java 8 you can provide default implementations for the methods in an interface and the only differences to an abstract class are constructors (which you don't use anyway apparently) and fields which should be private, so there's very little difference. – borchero Jul 17 '15 at 14:08
  • 1
    Yes, as also a java 8 interface with an implemented default method. Providing a default base class with interfaces does happen sufficiently often (i.e. in swing), and in itself is a helpful, supportive practice. Maybe try to make only `final` public methods, indicating a prescriptive behavior/additional information. One advantage: you can have `protected` methods to override. – Joop Eggen Jul 17 '15 at 14:13
  • You may also be interested in [Abstract Factory vs Factory Method](https://stackoverflow.com/questions/4209791/design-patterns-abstract-factory-vs-factory-method/38668246#38668246). – jaco0646 Nov 28 '18 at 14:49

2 Answers2

12

I would go with yes.

Lets look at definition of Factory method pattern:

the factory method pattern is a creational pattern which uses factory methods to deal with the problem of creating objects without specifying the exact class of object that will be created

The motivation behind this pattern is to separate object creation from the client using the object. Client should provide specification to factory but details how the object is built are abstracted away by the factory.

If this is an interface or abstract class is an implementation detail specific to situation, as long as your implementation of the factory lets you achieve the motivation behind pattern.

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

  • You want to share code among several closely related classes.

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

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

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

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

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

  • You want to take advantage of multiple inheritance of type.

In some implementations it might even make more sense to use abstract class rather then interface for the Products created by the factory. If there is shared set of features/behavior between all products then it does make sense to put these into base abstract class. This could apply even if products are built from different factories.

It boils down to: do you wish to and does it make sense to introduce coupling between products or not? In the end, client will get same result - Product built based upon specification, with details of construction abstracted away.

Community
  • 1
  • 1
John
  • 5,189
  • 2
  • 38
  • 62
1

When it comes to these kind of differences, the answer can always be both yes and no. Design patterns are not any kind of precise 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 this would not be a factory pattern. And it does not have to be, as long as it solves your use case and makes the code readable and maintainable (trying to literally adhere to design patterns often leads to misusing them and to over-architecturing).

If we look at the Abstract Factory Pattern (right below the Factory Pattern in the linked page), we'll see that it is a factory for creating factories. Now suppose that we have two Shape factories that can be created by the AbstractFactory: ShapeFactory2D and ShapeFactory3D, both producing Shape objects.

If Shape were abstract class, then you would force both 2D and 3D objects to inherit the same implementation, although it might make no sense (they could be implemented in totally different ways).

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

Of course you can have Abstract2DShape and Abstract3DShape abstract classes implementing Shape; the point is that you are able to create and use Shape without being aware whether it is a 2D or a 3D shape.

Dragan Bozanovic
  • 23,102
  • 5
  • 43
  • 110
  • 1
    But OP didn't ask about Abstract factory pattern, and therefore 4 out of 6 paragraphs in this answer aren't relevant for the question. – John Jul 17 '15 at 15:04
  • The answer describes how _Factory Pattern_ is used in the application. _Abstract Factory Pattern_ is just an example of how factories are used (at the end they will be used in some way, otherwise it makes no sense to implement them). – Dragan Bozanovic Jul 17 '15 at 15:08