• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

static methods for object creation

 
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All

From this forum I gathered that its better to have all object creation code inside static methods.

Can someone highlight the benefits of the same

Rgrds
Mohit
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

From this forum I gathered that its better to have all object creation code inside static methods.



Please pass the links.
 
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
These static methods are called factory methods. I use quite a lot of them when I am creating GUI for my application or accessing third party librarys ; initiate the widget set its properties, colour, size etc link them up with other relevant widgets before returning it.

Python example
button=GUIFactory(parent,�button�, size=23,colour=�red�,bla bla bla..)

This is what I call data hiding because it hides how the object is constructed away from the rest of the application. This button widget could be implemented by any gui tookit wxWidget, Tkinter Swing for JPython you name it. But almost of the time only the implementation of the factory method only need to change.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerald Davis:
These static methods are called factory methods.



Actually it's better to call them creation methods, so that they don't get confused with the Factory Method pattern.
 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mohit Sinha:
Hi All

From this forum I gathered that its better to have all object creation code inside static methods.



Too much generalization is always bad - either in design or in real life! As others mentioned, while Factory and Singleton tend to use static methods where objects are created, it does not have to be for all. Other 'creational' patterns have different approaches.
 
author
Posts: 200
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree, we call object creation within static method "Static Factory" rather than "Factory Method" so as not to confuse the two. They are definitely different.

You will see object creation within static methods in Static Factory, and also in Singleton.
But it's by no means the only way to create objects! (Obviously).

The nice thing about static factory is that it's global and you have control over the instances it creates. As an example:

public static Boolean valueOf(boolean b) {
����return (b ? Boolean.TRUE : Boolean.False);
}

(This is from an example at Javaworld.com).

The advantage here is that this static method can reuse instances! I think of this as the primary advantage to static factory (and overlaps with the Singleton pattern here too).

The disdvantage of static factory (and, correspondingly, the advantage of Factory Method) is that you can't subclass. In Factory Method, the primary reason for subclassing is to plug in your own objects easily, without having to change any code. So if your factory superclass implements code that relies on "CheesePizza", but uses a factory method to create that pizza, you can easily plug in different implementations of "CheesePizza" without having to change the code in the factory superclass that *uses* it. This is the important difference in these two patterns, and a good reason not to confuse the names.

Elisabeth
 
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Elizabeth,

Does the book differentiate b/w plain Factory and the AbstractFactory patterns ?

I can think of another way to create objects i.e. by using reflection. What would be others, that you alluded to in your reply ?

Could I generalize that a "static factory that returns type X" usually resides within the same Class of type X; whereas factory methods could reside in a separate class from the actual type that it returns ?
 
Elisabeth Robson
author
Posts: 200
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The book differentiates between three types of "factory" patterns: Simple Factory, Factory Method and Abstract Factory, and alludes to Static Factory as a fourth variation, although no examples of this are given in the book.

One way to create objects in Java that's often used with one of the factory patterns is to use Class.forName(). This allows you to pass a string to the factory that identifies the class to instantiate, and thus make the factory very flexible.

I would say your generalization is probably accurate. The design of Factory Method is to subclass to allow subclasses to create the different types, and then to instantiate the right factory to get the type you want.

Elisabeth
 
Mohit Sinha
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Elisabeth

Could you ellaborate a bit on this advantage of static factory

************
The advantage here is that this static method can reuse instances! I think of this as the primary advantage to static factory (and overlaps with the Singleton pattern here too).
************

I did not get this. Can you post a small example


Rgrds
Mohit
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


Actually it's better to call them creation methods, so that they don't get confused with the Factory Method pattern.



Isn't Fatory method pattern a creational pattern? :roll:
 
Ranch Hand
Posts: 1211
Mac IntelliJ IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Factories is one of the creational patterns.
Not all such static object creation methods may fit the Factory Method pattern.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Pradeep Bhat:


Isn't Fatory method pattern a creational pattern? :roll:



Yes, of course. But Factory Method is much more than just a single method creating an object - it actually involves a whole hierarchy of classes, where the base class calls an abstract creation method, which gets implemented by the subclasses.

Does that help?
 
Elisabeth Robson
author
Posts: 200
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, in static factory, you've only got one instance of the creation method. If that creation method returns the ONE instance of an object then you are assured that you've only got one instance of the object you're returning running around.

E.g. a static creation method in a factory could return the one instance of an object created by the factory:

public class StaticFactory {
static MyObjInterface myObj = new MyObj();

public static MyObjInterface createObjInterface() {
return myObj;
}
}

Implemented this way a static factory is very similar to a singleton, except of course the type of the object being returned isn't the factory itself. Also, you can parameterize the create method to return one of several objects.

Elisabeth
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There was a blog referenced here recently - Martin Folwer? Robert Martin? Martin Martin? - about separation of object creation from object usage. "new classname()" is pretty tight coupling, so it considered the idea of every class having a static factory method for itself as the least possible factory. "every" is probably overkill, but how do you know when it's safe to hardcode class creation and when it might be useful to substitute a subclass or a family of subclasses later? There is no right answer of course; one reason we can expect to improve with age.

Example:

We can change this to use any kind of factory logic later without telling any clients.
 
Sathya Srinivasan
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
but how do you know when it's safe to hardcode class creation and when it might be useful to substitute a subclass or a family of subclasses later?



I guess this is exactly the reason why refactoring and TDD approach is useful. You should never over-engineer your code. You should always do whatever works and then fine tune it once you are sure that the feature works correctly.

The rule: "Make it work, Make it right, Make it optimal" almost always holds true.
reply
    Bookmark Topic Watch Topic
  • New Topic