• Post Reply Bookmark Topic Watch Topic
  • New Topic

factory pattern vs direct component association  RSS feed

 
s ravi chandran
Ranch Hand
Posts: 579
6
Java jQuery
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am working on a task where I have defined two components A and B. All the components are loaded through Spring DI. Component A calls a factory class to obtain instance of Component B. There are few variations of Component B, lets say they are B1, B2 and B3.

Based on one of the attribute of object received from Component A, I decide which variant of B I will return.

This looks like a cleaner code to me, sort of event driven as the model object defines the type of B returned.


My senior has another suggestion, to define all the variants in Spring and associate them directly for each case. His argument is that this is save some time that will be taken for the IF conditions in Factory class.

My question is how much can be performance overhead if say there are 10000 model objects were to be passed.
 
Tim Cooke
Marshal
Posts: 4048
239
Clojure IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For your solution, your factory would look something like this?


Coming to your senior's suggestion
ravi's senior wrote:... and associate them directly for each case

Can you show an example of what is meant by that? I don't quite follow.
 
s ravi chandran
Ranch Hand
Posts: 579
6
Java jQuery
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That would look like this:
 
s ravi chandran
Ranch Hand
Posts: 579
6
Java jQuery
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
my suggesion was something like this:



Objective is to abstract out all components. This way component A doesnt know about component B and component B doesnt know about component A.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I have done in the past is to have the Factory class expose a register(T handler) or register(List<T> handlers) method that you can call any number of times or with a list that contains any number of classes. On startup, you can call these methods to register whatever available handlers you have and map them to the appropriate attribute value they will be assigned to handle.  This allows you to eliminate a long switch or if-then-else statement and replace it with just one Map.get() call.  Your Factory class will never have to be changed when you add new handlers in the future. Just add more calls to the register method or add more items to the List of handlers that you pass to it. 

I would recommend defining an Enum type if you have a limited number of attribute values to key off of. Then define a Handler interface:
 
s ravi chandran
Ranch Hand
Posts: 579
6
Java jQuery
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This looks good.

I hope my senior would not debate on performance aspect with this. This will have time complexity of O(1) if I use hashmap. That leaves the performance argument out of the window.

I will try to enhance my design with this idea.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been learning Go and the philosophy in that language is really hardcore on the Interface Segregation Principle (ISP).  Now that I think about it, I would separate that into two interfaces:

Then, your Factory methods would be:

The cast on Line 4 enforces a "rule" that any object that is Registerable also needs to be a WhateverHandler. This will cause a ClassCastException if the handler class that's being registered only implements Registerable but doesn't implement WhateverHandler. That's something that you should catch during testing; it should never happen in production. You could also put a try-catch around it and just ignore anything that does not conform to the rule. It all depends on how lenient or strict you want your Factory to be and what repercussions that may have to the rest of the application.

Caveat: All this is just off the top of my head. I have done these kinds of things before but I haven't actually tried any of the specific code I posted here.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
s ravi chandran wrote:I hope my senior would not debate on performance aspect with this. This will have time complexity of O(1) if I use hashmap. That leaves the performance argument out of the window.

Only worry about performance if you can quantitatively prove, with benchmarking and profiling, that you have a performance problem. DON'T optimize on gut feelings and intuition. That's a horrible approach.  Donald Knuth (apparently quoting C.A.R. Hoare) said, "Premature optimization is the root of all evil."  Don't be evil.
 
s ravi chandran
Ranch Hand
Posts: 579
6
Java jQuery
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:
s ravi chandran wrote:I hope my senior would not debate on performance aspect with this. This will have time complexity of O(1) if I use hashmap. That leaves the performance argument out of the window.

Only worry about performance if you can quantitatively prove, with benchmarking and profiling, that you have a performance problem. DON'T optimize on gut feelings and intuition. That's a horrible approach.  Donald Knuth (apparently quoting C.A.R. Hoare) said, "Premature optimization is the root of all evil."  Don't be evil.

Hard to argue when the argument comes from a senior person.

I just did not accept the solution that I was told. Hence working on optimizing my solution while maintaining decoupling.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
s ravi chandran wrote:Hard to argue when the argument comes from a senior person.

I just did not accept the solution that I was told. Hence working on optimizing my solution while maintaining decoupling.

Well, I'm sorry you're in a situation where you feel like you have to do that then. Have you tried reasoning with this person? Maybe he/she doesn't realize that optimizing based on gut feelings and intuition is not a very scientific or technical way of doing things. Good engineers have good instincts but they should never trust them too much to skip measuring and verifying. Hard numbers are indisputable, feelings and instincts are not.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!