whats the point of factories?
Hi
I have seen several places that socalled factories are used in order to create objects. This has the effect that first you need to create a factory and then use this factory to create the objekt. Wouldnt it be easier to just create the object using the new operator?
Let me give you an example (SAX):
publicstaticvoid main(String argv[])
{
if (argv.length != 1){
System.err.println("Usage: cmd filename");
System.exit(1);
}
// Use an instance of ourselves as the SAX event handler
DefaultHandler handler =new Echo();
// Use the default (non-validating) parser
SAXParserFactory factory = SAXParserFactory.newInstance();
try{
// Set up output stream
out =new OutputStreamWriter(System.out,"UTF8");
// Parse the input
SAXParser saxParser = factory.newSAXParser();
saxParser.parse(new File(argv[0]), handler );
}catch (Throwable t){
t.printStackTrace();
}
System.exit(0);
}
Here you first need to create a SAXParserFactory which has no better usage than just creating a new SAXParser...in my honest opinion the same should have been able to do with only:
SAXParser parser = new SAXParser
This would better follow the object oriented design in my opinion, and would reduce the number of objects to create.
Can anyone explain this factory method for me?
[2108 byte] By [
invictus2a] at [2007-11-27 6:48:45]
> in my honest opinion the same should have been able to do with only:
> SAXParser parser = new SAXParser
it's an abstract class
> This would better follow the object oriented design in my opinion,
this opinion, can you elaborate?
> and would reduce the number of objects to create.
it would tie you to one implementation. it would increase the number of concrete types a user would have to know. it would increase coupling and decrease flexibility
> Can anyone explain this factory method for me?
the point is the client code does not need to know which concrete implementation is used, so that the latter can change without impacting the former
The example you chose may not look like the most obvious to you.
I'll take another example :
Say you're developing an application that needs to be run on different DBMSs. Do you want to use each time the concrete implementation of, say, java.sql.Connection for each JDBC driver ?
No, you'll tie your code to java.sql.Connection and use DriverManager.getConnection(<driverName>). All you need to do is change the <driverName>, for instance by changing a simple configuration file.
Some advantages of factory methods are:
You can return any subclass of a declared type
You don't have to create an object each time they are invoked (especially useful for immutable classes)
You can give factory methods descriptive names and because of this you can have factory methods in the same class that have the same formal parameters.
-
YoGeea at 2007-7-12 18:22:15 >
> Do you really need that many implementations?
"need" is not the point per se. there _are_ several implementations, and different ones may be available in different environments.
why, in your opinion, would it be better if you had to know the concrete types, and to write your code so that you'd have to change it to switch implementations? what do you feel would be the benefit of having to change your code, versus the current ability to change it through external configuration (see the API docs for SAXParser for how).
ignorance of concrete types is bliss (and the point of OO languages).
