Should I use AbstractFactory design pattern in this kind of a problem?
Depends on if the problem you have is the kind of problem that the Abstract Factory pattern provides a solution for. So let's look at that, and then, hopefully, you'll be able to decide for yourself.
An abstract factory is essentially a glorified collection of constructors that you can override. It provides a number of related factory methods for creating a family1 of objects, without requiring client code to know the concrete types of those objects - those types are set or configured somewhere else.
1 "family of objects" is just a fancy name for a "set of objects"; the word is used for style or to emphasize relatedness.
So, in the general case, there isn't just a single makeShape method. As described in the Design Patterns book, there are several methods, all of which return an abstraction of some product:
Am I correct that using ObjA as a parameter is against the idea of using abstract factory design pattern?
No! The pattern doesn't specify at all what the parameters to the creator methods should be - that's up to you (and the way you represented what you're trying to do in code).
There are different variations of the pattern; the example you've referenced uses a type-discriminating string to replace all the methods in the above diagram with a single method that dispatches on that parameter:
abstract Shape getShape(String shapeType)
But a) that's not the point of the pattern, and b) they can only do that because none of the concrete shapes require any parameters to be created. In general, each creator method can have it's own set of parameters - it all depends on how client code is going to use the abstract factory.
E.g., the sample code in Design Patterns provides this abstract factory:
public abstract class MazeFactory {
abstract Maze makeMaze();
abstract Wall makeWall();
abstract Room makeRoom(int roomNumber);
abstract Door makeDoor(Room roomA, Room roomB);
}
The idea is that there's a need to introduce a different set of subclasses of Maze, Wall, Room & Door that need to work together. However, client code that invokes the creation of each object shouldn't worry about mixing up incompatible subclasses. The abstract MazeFactory takes on this responsibility, letting the client code to change from:
Maze createMaze() {
Maze maze = new Maze();
Room r1 = new Room(1);
Room r2 = new Room(2);
// ...
Door door = new Door(r1, r2);
//...
maze.AddRoom(r1);
maze.AddRoom(r2);
//...
return maze;
}
to:
// 'factory' is instantiated elsewhere - e.g. in main()
Maze createMaze(MazeFactory factory) {
Maze maze = factory.makeMaze();
Room r1 = factory.makeRoom(1);
Room r2 = factory.makeRoom(2);
// ...
Door door = factory.makeDoor(r1, r2);
//...
maze.AddRoom(r1);
maze.AddRoom(r2);
//...
return maze;
}
Patterns aren't about the exact structure. They are about a general approach to solving a particular class of problems - details of the structure can vary. The pattern doesn't even require you to have subclasses of the abstract factory. The factory is abstract in the sense that it provides a programmer-defined abstraction for creating objects. It can, for example, be a concrete class that offers "slots" where you can plug in prototypical instances of each product, and then each creation method would return a copy of the prototypical instance on demand (perhaps modifying some of its properties first). This is also discussed in Design Patterns as a way to avoid combinatorial explosion of factory subclasses.
This creates the problem that the modules are linked together by ObjA.
ObjA is not the problem in itself. Every concrete factory is necessarily linked together (more precisely, depends on) the module that contains the concrete types of the products. This may be less obvious if you're using something like reflection, relying on type names to "magically" instantiate concrete objects (because the concrete implementation of your abstract factory is essentially provided by some other mechanism), but just try changing the name of some concrete type and you'll see that the whole thing breaks.
This is not where the decoupling happens. The concrete factory and concrete products go together. The decoupling happens at the abstract/concrete boundary, something like this:
What's decoupled here is (core high-level logic) vs (implementation of variation 1) vs (implementation of variation 2). You can write the high-level logic without worrying about implementation details of a variation, and you can easily reconfigure your app to use a different variation. You can also provide a new variation by deriving a new family of subclasses, without changing the high-level code. Each variation is essentially like a plugin.
If your 'ObjA' is a part of the abstract factory's interface, then it needs to be in the abstract ("high-level logic") part. Otherwise, if you're using the approach based on the prototypical instances, you may pass 'ObjA' to the concrete constructor of the prototype. A variation of that is: instead of prototypical instances, plug in lambdas that close over 'ObjA' and potentially take extra parameters to create the final product.
Now, what remains is to reconsider your problem in this light and see if it has this "shape", to put it that way. If not, then this may not be the right pattern.
