"Static factory methods", constructors

Post #143,210 by CRConrad 2/25/04 10:23:58 AM Reply	"Static factory methods", constructors - what's the diff? In response to "Simon Jester" suggesting: 2nd - create a second constructor and use polymorphism to reduce the number of arguments. ie: foo (argument1, argument2, ... argumentN) foo (argument1, argument2) { foo(argument1,argument2, argument3 = null; argument4 = null; ... argumentN = null)) }; , AdminiScott goes: 2) Incorrect. In Oracle 8 there is one constructor, which takes all of the object's members as arguments. This is required as you may not set default values for arguments in the constructor. The workaround is to create static factory methods (NOT constructors) that internally create default values and call the system constructor with all of the attributes set appropriately. What's the diff, exactly? Does it apply to all OO languages, or only those with a "system constructor"()? (I realise that you guys were talking about PL/SQL specifically, where that applies, but I thought this bears discussion in more general "philosophical" terms.) Aren't all constructors, basically, commands to a `class` -- "gimme an instance of yourself"? I mean, wouldn't the principle of encapsulation argue for putting constructor code in the `class` definition(), rather than as "free-floating" functions on some "system"(*) level? To sum up, isn't a "static" (or "class") method that returns a new instance -- a "factory" method, if you will -- what a constructor, on the most fundamental level, IS? As you've all no doubt discerned by now, I think so; and furthermore, I think the language syntax should reflect that -- something like "`MyClass aNewObject = MyClass.makeAnInstance(foo, bar...);`" -- no silly free-floating "new" and crap; just an order to the relevant entity, the class, to provide an object instance. Isn't this much "cleaner" and more logical than the alternative? If not, why not? (BTW, no prizes for guessing which language works exactly that way. :-) (): As exemplified by the C++ / Java keyword "`new`", I suppose. (): And AFAIK, most OO languages -- C++ and Java among them -- do exactly that. (): Which would be what "`new`" looks like -- and which makes it a counter-intuitive "not-very-OO-feeling" aberration, IMnshO. P.S: Yes, I think* I see one possible practical difference, where a "factory method" differs from a constructor in how you code and use it; will hafta check that out before I talk any more about it. [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) You know you're doing good work when you get flamed by an idiot. -- [link\|http://www.theregister.co.uk/content/35/34218.html\|Andrew Wittbrodt]
Post #143,224 by admin 2/25/04 11:34:53 AM Reply	Inheritance. The main difference deals with inheritance. If you use constructors, you can call superclass constructors more transparently. With a factory method, you have to call the more general factory method, then use some sort of set/get construction to further refine the class. You're hosed, however, if you need a narrower class and the more general factory method isn't capable of creating it. This is a somewhat difficult discussion to have in general, as languages deal with this in so many different ways. In Perl, for example, instances are just hashes that get "blessed" as a particular class. So you can have a different factory method that returns a wider class and then bless it in a narrower definition. I don't have a preference between 'new' and newInstance-like methods, as long as the newInstance kind provides inherited constructor functionality. Again, Perl acts in the manner you describe: you can name the constructor whatever you wish, and calling it provides a blessed instance. With Python, you just do "foo = FooClass(a, b)". No new keyword, and no factory method either. :-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #143,283 by dshellman 2/25/04 4:29:44 PM Reply	Static factories vs. constructors There are lots of langauges and many of them handle this differently, but since the examples appear to be more Java-ish (the original post was about Java, at least), I answer based upon that: In most cases, the difference is more preference than anything. Ultimately, a chunk of memory gets allocated, a reference associated with it, and potentially, one more more methods are executed. There are several advantages to using static factories (though that does not imply that they should be used above all else), such as: being capable of returning a more generic type than a contructor, and separating the construction of objects from where they are accessed from. A couple of examples: When using the "new" keyword (standard constructor mechanics), the type returned is known at compile-time. However, a static factory method may return a more generic type, leaving the details of construction and choice of the actual constructed object hidden from view (view from the caller). In Java, for example, a static factory may produce objects that implement a particular interface. Using the "new" keyword means the the decision about which actual class is constructed has already been decided. This may be a good thing, and it may not matter (depending upon how it's used). It's common for developers who do heavy unit testing (at least in the Java world) to use static factories so that they can more easily factor out the construction of objects (i.e. the use of mock objects). This helps make their code more "testable." Again, this is not to suggest that this is a good method of doing this, but that it is a common idiom. Dan

Welcome to IWETHEY!