[SOLVED] Aim of Factory pattern is to stop us from over-riding or re-writing the functions which instantiate?

Aquarius_Girl · 01-12-2017, 01:43 AM

http://www.cs.unc.edu/~stotts/GOF/hires/pat3cfso.htm

`CreateMaze` is the function which instantiates the objects.
IMO, according to factory pattern we are not supposed to overload
or modify or re-write the function which instantiates objects.

But in the example, the CreateMaze function returns a Maze*.
So, now if we have to write an EnchangedMaze class, will we have
to re-write CreateMaze function to return a pointer of EnchantedMaze?

From: http://www.cs.unc.edu/~stotts/GOF/hires/chap3fso.htm

>Changing the layout means changing this member function, either by
overriding it—which means reimplementing the whole thing—or by changing
parts of it—which is error-prone and doesn't promote reuse.

Isn't this what factory pattern wants to avoid?

What point am I missing?

ntubski · 01-12-2017, 07:35 AM

Quote:

Originally Posted by TheIndependentAquarius

>Changing the layout means changing this member function, either by
overriding it—which means reimplementing the whole thing—or by changing
parts of it—which is error-prone and doesn't promote reuse.

Isn't this what factory pattern wants to avoid?

What point am I missing?

That example isn't using the factory pattern. Near the bottom of that page:

Quote:

If CreateMaze calls virtual functions instead of constructor calls to create the rooms, walls, and doors it requires, then you can change the classes that get instantiated by making a subclass of MazeGame and redefining those virtual functions. This approach is an example of the Factory Method (107) pattern.

sundialsvcs · 01-12-2017, 08:31 AM

Obviously I don't like being asked obvious homework

questions, but this is a fairly good one.

The essential notion of "a 'factory'" is that you have a case where, in order to 'manufacture' an instance of an object, you need information that a simple constructor would not have, in order to populate the instance properly. (For instance, if a "room" is part of a "maze," don't design a "room" constructor that is given a "maze" reference: design a "create-room" method of a "maze" which generates "'my' rooms." Why? Because, "the maze knows best." And, furthermore, for years to come, as the project changes and grows, it will still "know best" what to do "today.")

If a "maze" needs a factory, then an "enchanted" maze might need another factory ... which might, behind the scenes, avail itself of the same logic needed to produce "mazes in-general."

But the crucial idea here is that "you always want to be able to find the factory/construction logic," in one predictable place: "factory row." It's very tempting for computer programmers to "try to solve 'the problem of the moment,'" doing something "on the spot" that "works for them, now, to close this ticket," without fully considering the big picture. This is the sort of thing

that causes their colleagues to throw darts at their picture.

Aquarius_Girl · 01-12-2017, 10:59 PM

@ntubski

I know there is a separate thing called Abstract factory pattern. But,
that's not what we are talking about here.

Do you mean to say that Factory pattern and Factory method pattern are
different things?

Assuming the above example is of Factory method pattern, can you explain
what is Factory pattern then?

ntubski · 01-13-2017, 10:15 AM

Quote:

Originally Posted by TheIndependentAquarius

Do you mean to say that Factory pattern and Factory method pattern are
different things?

No, I meant to say that the example you were holding up as something the factory pattern was supposed to avoid, had not yet had any factory pattern applied to it, i.e., it was purposely constructed to demonstrate those problems.

Regarding "Factory" vs "Factory method" vs "Abstract Factory" see https://en.wikipedia.org/wiki/Factor...rn#Terminology

Quote:

Terminology differs as to whether the concept of a factory is itself a design pattern – in the seminal book Design Patterns there is no "factory pattern", but instead two patterns (factory method pattern and abstract factory pattern) that use factories. Some sources refer to the concept as the factory pattern,[2][3] while others consider the concept itself a programming idiom,[4] reserving the term "factory pattern" or "factory patterns" to more complicated patterns that use factories, most often the factory method pattern; in this context, the concept of a factory itself may be referred to as a simple factory.[4] In other contexts, particularly the Python language, "factory" itself is used, as in this article.[5] More broadly, "factory" may be applied not just to an object that returns objects from some method call, but to a subroutine that returns objects, as in a factory function (even if functions are not objects) or factory method.[6] Because in many languages factories are invoked by calling a method, the general concept of a factory is often confused with the specific factory method pattern design pattern.

sundialsvcs · 01-17-2017, 08:42 AM

A "pattern" is necessarily a generalization, meant for illustration and description. It is not a diktat. You probably won't find any application in the real world that religiously adheres to any pattern, but patterns are a useful way to describe algorithms and software designs that have worked in real cases for real people.