Talk:Factory method pattern

From Wikipedia, the free encyclopedia

	This article is within the scope of WikiProject Computer science, which aims to create a comprehensive computer science reference for Wikipedia. Visit the project page for more information and to join in on related discussions.
Start	rated as Start-Class on the assessment scale
Mid	rated as mid-importance on the assessment scale

[edit] What's the advantage?

How is this any better than providing parameterized constructors in a class and having the client call the appropriate one? It seems using a class factory presents no clear advantages compared to the normal method of calling the correct parameterized constructor from the client code. What advantages do factories have? —Preceding unsigned comment added by 68.100.251.126 (talk) 16:39, 29 January 2008 (UTC)

Try writing the Complex class example in the article, and you will see the advantage. Esben (talk) 18:28, 6 February 2008 (UTC)

[edit] Article doesn't really describe the GoF pattern?

Sorry for butting in but the article doesn't actually explain anything. If one is a newcomer it doesn't make any sense. For those who already know it, there is no need for the article ... Bill. —Preceding unsigned comment added by 220.233.122.121 (talk) 13:39, 26 November 2007 (UTC)

In my understanding, the GoF Factory Method pattern is much more specific than the description in the article. It is like a specialization of the Template Method pattern - the methods defined in the subclasses are actually called in the base class and not part of the public interface.

Most of the article seems to be describing something more along the ways of the Abstract Factory pattern, a specialization of the Strategy pattern, where the methods defined are meant to be called by clients outside the class hierarchy.

The "Descriptive Names" example, on the other hand, seems to describe neither Factory Method, nor Abstract Factory, as both those patterns rely heavily on polymorphism. They are more of what Joshua Kerievsky calls "Creation Methods" in his book "Refactoring to Patterns".

Most of the examples u have shown is in c++,java , currently i am working on .net platform, can you put some examples in .net , so i will have more clear view!

.NET is not a language; as you said, it is a platform. However, Java is very similar to C# to the extent that these examples probably make sense just fine in the context of C#. If you were asking for VB.NET examples, well, please learn to read other languages. It's always sad to see developers that eternally stick themselves in VB land. --130.127.53.144 (talk) 15:59, 13 March 2008 (UTC)

[edit] Games comment

I don't think the extra paragraph on games in 'Comon Usage' adds anything to the article at least not in it's current form, so I've commented it out...

[edit] ImageReaderFactory::ImageReader returns pointer not value

ImageReaderFactory::ImageReader is declared to return a value (object of class ImageReader) but actually returns a pointer.

ups.. my fault. seems it's supposed to be Java.

[edit] is this c++ ?

• if it is then code should be more c++ like, otherwise you should state that this is a java piece of code,

consider the following code :

class Complex { public: static Complex fromCartesian(double real, double imag) {

       return new Complex(real, imag);
   } 

static Complex fromPolar(double rho, double theta) {

       return new Complex(rho * cos(theta), rho * sin(theta));
   }

private: Complex(double a, double b) {

       //...
   }

};

Complex c = Complex::fromPolar(1, pi); // Same as fromCartesian(-1, 0)

[edit] The third limitation

The third limitation in the Limitations section has an unsubstantiated comment, "this is risky but possible". I do not see the risk.

I too do not see this risk. The entire point of the protected keyword is to allow inherited classes access to methods. --Odie5533 02:07, 5 August 2007 (UTC)

The third limitation does not really concern that case. Using the protected keyword will in fact allow inheritance of the constructor, but the subclass must still implement its own methods to call its own inherited constructor. Therefore, perhaps the wording was incorrect, but the idea that it is risky to attempt to use inheritance in that situation holds true and it is important to be explicit about the inheritance limitation of this pattern. 192.5.246.220 (talk) 01:33, 19 March 2008 (UTC)

[edit] Misunderstanding in Citation

All three problems can be alleviated by making factories
first-class class members rather than using the design pattern.. [1]

The actual citation from the text is as follows:

Interface (or protocol) can be separated from
implementation, but in order to select a particular
implementation of a given protocol one must be familiar
with at least one of these implementations. Our solution
to this cyclic dilemma is by making the selection of an
implementation part of the interface. In the
object-oriented terminology, this means that we allow a
class to offer a set of services, what we call factories,
for generating instances of its various subclasses.
Factories are first-class class members (alongside
methods and constructors), but, unlike constructors,
factories encapsulate instance management decisions
without affecting the class’s clients.

After reading that, the original statement about solving the problems doesn't make any sense to me and seems incorrect. --Odie5533 02:14, 5 August 2007 (UTC)

[edit] Complex example

The complex number example doesn't seem to be an example of the factory method pattern. In all cases, a Complex class is instantiated. —Ben FrantzDale 07:02, 12 November 2007 (UTC)

The problem seems to be that this page is redirected to from factory method. The idiom to use functions that return objects but are not constructors are sometimes called (perhaps mistakenly?) factory methods, and sometimes "named constructors" (which has no page). Not sure what to do in this case, as the idiom is pretty common in the many languages which requires the constructor to have a specific name (C++, Java are two obvious examples). Personally, I'd argue that limiting factory methods to the case where references to subclasses are returned is a worthless restriction. The idea remains the same. However, I realize that my personally opinion should not matter. Esben 10:16, 13 November 2007 (UTC)

[edit] Complex Java example - would this be an improvement?

My use case of the article is as a reader trying to understand the Factory design pattern in a Java context. As I understand one of the purposes with encapsulating the constructor and use static factory methods in the object creation process to make it clearer wich arguments should be used (Cartesian or polar). However, I think the example is still ambigious as the argumentss can easily be swapped. Both are of the real type, so in principle the user of the creator method could swap, e.g., the real and imaginary part in the fromCartesian method. Would it not be clearer to modify the example into the following?

class Complex 
{
     public static Complex fromRealAndImaginary(double real, double imag) {
         return new Complex(real, imag);
     }
 
     public static Complex fromModulusAndAngle(double rho, double theta) {
         return new Complex(rho * cos(theta), rho * sin(theta));
     }
 
     private Complex(double a, double b) {
         //...
     }
}
 
 Complex c = Complex.fromModulusAndAngle(1, pi); // Same as fromRealAndImaginary(-1, 0)

-- Slaunger (talk) 08:27, 21 November 2007 (UTC)

First of all, the language is irrelevant. Second, as for the names of the methods, your examples are much more verbose, and adds very little, since the names of the parameters should tell the user which one is what (in the polar variant, the arguments should be "modulus" and "angle"... I will change that after this. But you do illustrate that the point mentioned above is very valid: The Complex example isn't really a factory (object) example, but an example of "named constructors" which are also sometimes called factory methods. Esben (talk) 08:40, 21 November 2007 (UTC)