Google Testing Blog: Where Have all the "new" Operators Gone?

Where Have all the "new" Operators Gone?

Thursday, September 11, 2008

Miško Hevery(the other title: Your Application has a Wiring Problem)My main() Method Is Better Than YoursHow to Think About the “new” Operatorremoving the new operators from the application logicmain() methodJettysource public Server buildServer() {
Server server = new Server();

SocketConnector socketConnector
= new SocketConnector();
socketConnector.setPort(8080);
server.addConnector(socketConnector);

new ServletBuilder(server)
.addServlet("/calc", new CalculatorServlet(
new Calculator()))
.addServlet("/time", new TimeServlet(
new Provider() {
public Date get() {
return new Date();
}
}));

return server;
}

"So now each class needs a factory, therefore I have twice as many classes!" Heavens No! Notice how our ServerFactory acted as a factory for many different classes. Looking at it I counted 7 or so classes which we instantiated in order to wire up our application. So it is not true that we have one to one correspondence. In theory you only need one Factory per object lifetime. You need one factory for all long-lived objects (your singletons) and one for all request-lifetime objects and so on. Now in practice we further split those by related concepts. (But that is a discussion for a separate blog article.) The important thing to realize is that: yes, you will have few more classes, but it will be no where close to doubling your load.

"If each object asks for its dependencies, than I will have to pass those dependencies through all of the callers. This will make it really hard to add new dependencies to the classes." The myth here is that call-graph and instantiation-graph are one and the same. We looked into this myth in Where have all the Singletons Gone. Notice that the Jetty server calls the TimeServlet which calls the Date. If the constructor of Date or TimeServlet all of a sudden needed a new argument it would not effect any of the callers. The only code which would have to change is factory class above. This is because we have isolated the instantiation/wiring problem into this factory class. So in reality this makes it easier to add dependencies not harder.

herehere public Server buildServer() {
Server server = new Server();

SocketConnector socketConnector
= new SocketConnector();
socketConnector.setPort(8080);
server.addConnector(socketConnector);

DBConnectionPool pool = new DBConnectionPool();
new ServletBuilder(server)
.addServlet("/calc", new CalculatorServlet(
pool,
new Calculator()))
.addServlet("/time", new TimeServlet(
pool,
new Provider() {
public Date get() {
return new Date();
}
}));

return server;
}

6 comments :

RichBSeptember 11, 2008 at 10:59:00 PM PDT
Does this technique coupled with minimal constructors inhibit const-correctness?
ReplyDelete
Pieter SwinkelsSeptember 12, 2008 at 12:35:00 AM PDT
Am I correct in saying that each object that instantiates objects of another class should (ideally) have a factory for that object as a dependency?

Let me clarify it with an example. I have a class Shipment whose method Shipment::plan instantiates a new Graph object. So Shipment depends on a factory that creates a Graph. Therefore I should make this dependency explicit, for example by passing a Graph factory to the Shipment constructor.
ReplyDelete
GiorgioSeptember 12, 2008 at 2:32:00 AM PDT
As Pieter, I also wondering how to instantiate a new object graph when I'm in a business object method. Note that instantiation is based on data of the method and so I cannot inject it from the constructor (like the Shipment class I have a db mapper that returns a new Collection class and so depends on this concrete class).
ReplyDelete
MiskoSeptember 12, 2008 at 10:28:00 AM PDT
@ Peter & @giorgio

Excellent questions about how to construct (what I call value objects) It is not something I can explain as a comment, so my next blog will cover that topic.
ReplyDelete
Jason RudolphSeptember 19, 2008 at 12:42:00 PM PDT
I've been a fan of the Google Testing blog for a good while now, and I frequently encourage others to add it to their feed reader. While the quality of the *message* has generally remained high, I'm bummed to see the quality of the *writing* take such a dip lately. And I'm not the only one that's noticed:

- https://www.blogger.com/comment.g?blogID=15045980&postID=3023874871164884317 - Arun says, "If you get past a number of typos and the non-working links, it looks like a hastily written, non-proofed copy."

- https://www.blogger.com/comment.g?blogID=15045980&postID=1997301458069663637 - Michael says, "3v1L fails the spellchecker unit test"

- https://www.blogger.com/comment.g?blogID=15045980&postID=3023874871164884317 - John Webber asks, "Miško, in the paragraph about static methods you refer to 'seems' - do you mean 'seams?' Otherwise I'm not sure what you mean."

As a grammar geek, it pains me to see the influential Google brand giving its stamp of approval to substandard writing. Good news: It's easily solved by having a peer proofread the post before publishing it. Peer reviews are just for code after all. ;-)
ReplyDelete
Patrick CopelandSeptember 19, 2008 at 2:56:00 PM PDT
It’s klear that we can do better on spell and grammer cheeking.

-- editor
ReplyDelete