• Post Reply Bookmark Topic Watch Topic
  • New Topic

why is this more OOP?  RSS feed

 
Hendra Kurniawan
Ranch Hand
Posts: 239
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
why do people keep saying that this:


is better than this:



what is the limitation of approach 2 to make approach 1 better?
 
Greg Brannon
Bartender
Posts: 563
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you provide a reference that includes the identity of "some people" and a location where their opinions can be read?
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is most likely from Item 1: Consider static factory methods instead of constructors from Joshua Bloch's "Effect Java Programming" book. There are pros and cons to using static factory methods over constructors.

Here's the last paragraph from that Item:
Joshua Bloch wrote:In summary, static factory methods and public constructors both have their uses, and it pays to understand their relative merits. Often static factories are preferable, so avoid the reflex to provide public constructors without first considering static factories.

I would emphasize: Avoid blind adherence to this item. Make sure you understand the relative merits of both static factories and public constructors -- Always remember "The Pot Roast Lesson"
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hendra Kurniawan wrote:why do people keep saying that this...is better than this:

Well, assuming Junilu is right, and you're referring to using factory methods - although a proper factory method would be:
SomeObject.createSomeObject();

there are several reasons; of which just a few are:

1. You can validate parameters before passing them to your constructor, which means that it can concentrate on the business of creating the object (and, if necessary, throw an Exception before creating anything).
2. You can give the method a nice, meaningful name.
3. You can return a subclass of the object without having to let your clients know (information hiding).
4. For immutable classes, you can return a cached version of the object - ie, you don't necessarily have to return a new one - You can find a good example of this practise in Integer.valueOf(int).

If however, you're referring to an 'object Factory', you should probably look at this page.

Winston
 
Hendra Kurniawan
Ranch Hand
Posts: 239
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank Winston, your explanation hits the bullseye. +1 for you.

@Greg: it's a discussion with my colleagues at work in the real world, not virtual world, so it can't be read. sorry.

 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hendra Kurniawan wrote:it's a discussion with my colleagues at work in the real world.

Then you should remind your colleagues that it's not about the one being more OOP than the other. Both are object-oriented. The considerations and decision to use one way or the other has to do with the robustness of the design.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!