2

I was just learning java .one of my colleague said that calling the class directly are not a good idea he asked me to use an factory method to create it. I have some questions regarding this:

  1. why do we need a factory function instead of creating the class directly?
  2. What is the use of it?
  3. will this consume object creation?
rb512
  • 6,880
  • 3
  • 36
  • 55
Ramesh
  • 2,295
  • 5
  • 35
  • 64
  • 6
    Maybe not in the spirit of Stack Overflow, but couldn't you try asking the colleague that said you should do this? Knowledge sharing around teams is essential, and building that relationship will help you grow your skills a lot more efficiently that posting on a website every time you have questions. – Daniel Attfield Oct 17 '11 at 12:31
  • 3
    Why don't you ask your colleague? If he has such an opinion (which might be good or bad, depending on the context), he should be able to back it up and explain it. – JB Nizet Oct 17 '11 at 12:32
  • 1
    Check out this post: http://stackoverflow.com/questions/7771729/best-practice-to-creating-objects-in-java – John B Oct 17 '11 at 12:33
  • yes you guys are correct i can ask my colleague but i thought stackoverflow can explain more than my colleague.i mean by many answers and many views. – Ramesh Oct 17 '11 at 12:39
  • ... the factory. If the factory is not planned to ever be replaced it is likely useless. What do you mean with "3. will this consume object creation"? Ah, I see, you only want a "factroy method"? That might make sense if you can factor out common code that way! – Angel O'Sphere Oct 19 '11 at 15:45

4 Answers4

1

You are not oblige to do this. You can also create a factory class. Take a look at this link to understand what is the aim of this pattern

Fred
  • 4,846
  • 1
  • 23
  • 21
0

There are a couple of reasons why you should do this. Some good. Some bad. Lets start with a bad reason:

  • Because everybody says so. Your coworker really should be able to explain why and you should ask him. Then judge his reasons.

A Better reason: It really boils down to the single responsibility principle (the S of SOLID)

If you have a class A and that instantiates a class B and calls that instance it really is a strong hint that you have combined two responsibilities. (creating and calling or to phrase it differently: deciding who should do something and letting it do it).

The remedy to this is to create the B instance outside of A and put it into A. Depending on the use case you have different options

  • create a B outside of A and stuff it into A through the constructor. This is the correct way to go if A needs the B in multiple places and it needs exactly one.

  • create a B outside of A and stuff it into A through some method call. This is the correct way if A needs the B(s) for a single interaction and needs/accept a different one on the next interaction.

  • pass a factory into A which A can use to create Bs at will. This is appropriate when A needs multiple Bs.

So this leaves the question: why is it so bad to use the constructor directly, instead of the factory, apart of violating some weired rule put up by a really smart person? If A creates Bs by calling the constructor for B it needs to know everything B needs for doing its work, which might be a lot of stuff and involve the necessety to create Cs, Ds and Es which themselves have dependencies which need to get created ... I think you see the point.

Jens Schauder
  • 77,657
  • 34
  • 181
  • 348
0

One of the reasons I can think of is avoid duplication of code. You may have the same code of creating the instance spread out, to avoid that, you can use this pattern.

allthenutsandbolts
  • 1,513
  • 1
  • 13
  • 34
0

One possible reason may be that gathering the objects that you need to pass as constructor arguments is repetitive, so combining this activity with the actual construction may avoid repetition without locking down how the new object's attributes are set.

Nicola Musatti
  • 17,834
  • 2
  • 46
  • 55