Talk:Abstract factory pattern

From Wikipedia, the free encyclopedia

Contents

[edit] Huge image

I realise this is really a technical problem with the software, but isn't a 173KB PNG image just a little excessive? This would take at least 30 seconds to grab over a 56kbps modem. Ideally the image should be palette-reduced, but it would help shrink it a lot if the diagram didn't contain fancy gradients. In any case the uploaded file should be in SVG format, to enable easier editing and scaling. We should probably also upload a temporary smaller PNG version for use in the article which is palette reduced. I'll take care of this and similar images in a while if there's no objection. Deco 15:51, 13 April 2006 (UTC)

I think the image is inappropriate because there's no reason to have the abstract factory have two different create methods. The static diagram (the UML class diagram) really only needs to show the different participants in the pattern in a clean, simple way. While this image does show the factory pattern I don't think it's the best way to show it. Also, I think it would be useful to show it in the context of the example code, if we're going to do GUIToolkits, then let's show GUIToolkits in the UML. Here's an example of what it could look like (much simpler). Also, this diagram and the notation that shows the roles of the classes in the pattern is inspired by Allen Holub's book Holub on Patterns.
Image:Abstract_factory.png
Bdean42 04:09, 3 September 2007 (UTC)
Looking at how terrible the image currently on the page looks, I say we should replace it with this new one as soon as possible. That is unless there are any objections. Bdean42 04:26, 3 September 2007 (UTC)
I changed the image to the new one. The old image can be found at here Bdean42 22:18, 3 September 2007 (UTC)
I just noticed that the UML class diagram that was previously used is nearly an exact copy of the one at the following link. The site it was copied from is copyrighted and has a terms of service that doesn't seem to be compatible with wikipedia. same thing here Bdean42 02:19, 4 September 2007 (UTC)

[edit] When to Use

I'd like to see a "When to use" Section along with a discussion of pros/cons about using this pattern.

[edit] JAVA Code Sample

Hello, i took the liberty of adding a Java code sample of the AbstractFactory example. It is very similar to the C# example, other than minor differences in language construct such as :/extends, public getters/setters etc. -- [Richard]

[edit] C++ Code Sample Error

The C++ examples make no sense.

From the article:
Adding new concrete types is done by modifying the client code to use a different factory, a modification which is typically one line in one file. (The different factory then creates objects of a different concrete type, but still returns a pointer of the same abstract type as before - thus insulating the client code from change.) This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created (as well as making sure that all such code locations also have knowledge of the new concrete type, by including for instance a concrete class header file). If all factory objects are stored globally in a singleton object, and all client code goes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object.

If you look at the Factory declaration it's a pure abstract class, since it has a virtual function who's address has been set to 0 (i.e it has no implementation). This means that you can't call getFactory without first getting a pointer to one of the concerete classes and you can't because you can't call getFactory.

[edit] Comment on behalf of 12.160.193.229

Someone should remove the autoptr - it confuses a reader inregards to the actual point of the article. JoshHolloway 17:44, 20 December 2006 (UTC)

[edit] Removal of other language examples

How come other language examples have been removed. They looked useful to me. There was no discussion here. Any reason? peterl 10:58, 5 March 2007 (UTC)

There are about 200 different languages listed in http://en.wikibooks.org/wiki/List_of_hello_world_programs . Where would you like the line be drawn? In my opinion even the current examples are too much. If an example is given, it should be given in pseudo code. —The preceding unsigned comment was added by 194.29.198.121 (talk) 12:30, 12 March 2007 (UTC).
Of course not 200. But more than one. Patterns like this are only relevant if the language has good support for modern OO principles. Personally, I'd choose C++ or C# or Java (my preference), maybe Perl or Python. I'm guessing Visual Prolog shows the techniques well, although it's not a language I'm familiar with. peterl 04:04, 13 March 2007 (UTC)

I think the examples are still too many and clutter the page. --M4gnum0n (talk) 08:57, 23 January 2008 (UTC)

I agree with you, that such an amount identical of examples (C# and Java examples differ very slightly!) is unnecessery. That's why I removed all but one (say Java). If you find it wrong, feel free to restore. qadro

[edit] Unrealistic / Inappropriate Example

The "Windows vs. OSX" button example is absurd. GUIFactory depends on both WinFactory and OSXFactory. This implies that the software can be compiled once and then deployed on either a Windows PC or an OSX machine; that it will contain code for both WinFactory and OSXFactory, and choose the correct one at runtime. OSXFactory and OSXButton will depend on some OSX headers and libraries that wouldn't exist on a Windows PC and vice versa. There is probably no way to successfully link/load this software, since only one set of headers will be available.

Ever heard of Java? "Write once, run anywhere" —Preceding unsigned comment added by 141.228.106.136 (talk) 16:50, 11 January 2008 (UTC)
Sorry, but do you really think that's what matters to people that come to this page? It's principle that's important here, not the details.
User:NickHounsome This is not just a detail. It is the reason why factory patterns are not as popular in C++ as in languages such as Java or C#. In those languages it is easy to remove all compile time dependencies from the factory by using configuration files, dynamic loading and reflection. There is no portable way to do this in C++.
In cases where "libraries" for multiple types of factory really are available it is possible in some circumstances to remove compile time dependencies using dictionaries initialized from the construction of static objects but this relies on having no static initializer requesting a factory and fiddling with the linker to ensure that the necessary object files are included as there will be no direct reference to them.