New is Glue

When you’re working in a strongly typed language like C# or Visual Basic, instantiating an object is done with the new keyword.  It’s important that we recognize the significance of using this keyword in our code, because I would venture to say that well over 90% of developers don’t give it a second thought.  Most developers have, at one time or another, heard the practice of building software applications likened to building something out of LEGO bricks (I’ve even written about LEGOs and software in the past).  A few days ago, it occurred to me that I could sum up my thoughts on this topic in three words, which I might hope would be memorable enough to “stick” in developers’ minds:

New is Glue

Any time you use the new keyword, you are gluing your code to a particular implementation.  You are permanently (short of editing, recompiling, and redeploying) hard-coding your application to work with a particular class’s implementation. 

That’s huge

That’s like your code’s getting married, forever and ever, until redeployment do us part.  Once you’ve said the words (new) and exchanged some vows (type metadata) and exited the church (deployed), changing your code’s chosen partner becomes a very expensive endeavor.  This is a big decision for you and your application.  You need to be very sure that this is the one and only implementation your code will ever need to work with, or else think about calling the whole thing off.

The marriage metaphor is taking things a bit far, I know, but let me add one more bit before we leave it behind us.  It’s quite likely that your code is going to need behavior from more than one other class.  In fact, it’s quite common that you’ll need to work with other classes in virtually every class within your application.  If you go the new route, that’s a lot of overlapping marriages that all need to stay happy for your application to work effectively.

But what if the behavior or service you need is only found in one place?  Maybe it’s not the perfect, now-and-forever class, but it’s the one that has what you need right now?  What am I suggesting, that one forego leveraging any other classes, and just do everything yourself?  Not at all, but let’s go with another metaphor now.

Favor Contractors over Employees

Your application requires certain services to do its job.  Think of your application like a small business.  There are things your application does, and things it needs to do its job.  A small business might need office space, and beyond that, certain utilities like electricity, phone service, internet service, shipping, etc.  In a business, relationships you have with service providers and contractors are relatively easy to change, while relationships you have with employees can be somewhat more difficult (for purposes of this analogy, pretend we’re talking about a country where firing people is very difficult/expensive).  Now think about which approach to running a small business makes more sense.

In the first scenario, your business’s needs are each met by a full-time resource.  You have Bob, the electrician, who ensures your electricity works, Joan, the telecom expert, who ensures your phone service is connected, and Joe, the truck driver, who takes care of delivering everything you ever need to send.  You also need an office to hold all of these people, which of course you leased with a 5 year lease that’s every expensive to get out of.

In the second scenario, your business’s needs are all met by service providers or contractors.  You use standard utility companies for electricity, phone, internet, and you can switch from one to another with only a small amount of pain if one fails you.  You ship with FedEx, USPS, UPS, etc. based on whichever one fits your needs of the day.  Your office space is just big enough for you, and since you’re still growing and aren’t sure how your needs will change, you’re paying month-to-month. 

Which of these two scenarios provides the greater degree of freedom for the business to adapt to future needs?  Which one is locked into a particular implementation and will be hard-pressed to change when needed?

Decoupling Services from Providers

New is Glue.  It binds your code to a particular collaborator.  If there is any chance you’ll need to be flexible about which implementation your code will need, it’s worth introducing an interface to keep your code loosely coupled.  It doesn’t matter what the service is you need – you can always replace it with an interface even if your class is the only one that uses it.  Let’s say your code needs send an email, with default code that looks like this:

using (var client = new SmtpClient())
using (var message = new MailMessage(fromEmail, toEmail))
{
    message.Subject = subject;
    message.Body = bodyHtml;
    message.IsBodyHtml = true;
    client.Send(message);
}
Note the two new keywords here, gluing whatever else this class is doing to this implementation of message sending.  This can be replaced with an interface like this one:
 
public interface IEmailClient
{
    void SendHtmlEmail(string fromEmail, string toEmail, string subject, string bodyHtml);
}

Now the code that used to contain the first block of code can be rewritten to simply use the interface:

public class SomeService
{
    private readonly IEmailClient _emailClient;
 
    public SomeService(IEmailClient emailClient)
    {
        _emailClient = emailClient;
    }
 
    public void DoStuff(User user)
    {
        string subject = "Test Subject";
        string bodyHtml = GetBody(user);
        _emailClient.SendHtmlEmail("noreply@whatever.com", 
user.EmailAddress, subject, bodyHtml);
    }
}

Edited: Please assume that DoStuff() does some useful value-added work, and that sending an email to the user is just something it does as a side effect, perhaps only when it’s successful, and not that it’s the main intent of the method, if that helps you think about the value of removing the dependency on SmtpClient.

How many new keywords are in this class, now?  Run a search in Visual Studio to find how many instances of new you’re using in your solution, and where.  Use ctrl-shift-F to find in files, search for “new”, Entire Solution, Match case, Match whole word, and Look at these file types: *.cs.

SNAGHTML2f30b1

Have a look at the total numbers, the numbers of files, etc.  In one very small ASP.NET MVC application I’m working on now, this search yields 280 matching lines in 25 files out of 47 files searched.  Four of the files and 28 of the matches are in my tests project.  The lion’s share of the rest of the matches are from SqlHelper.cs.  My controllers have a total of 7 matching lines, and all of these relate to creating model/viewmodel types, not services.

When is it Acceptable to use New?

Using new isn’t wrong, it’s a design decision.  Like all design decisions, it should be an informed decision, not a de facto one.  Use it when you don’t expect you’ll need flexibility in the future.  Use it when it won’t adversely affect the usability of your class by its clients.  Consider the transitivity of the dependencies you take on within your class – that is, how the things you depend on in turn become dependencies for classes that use your classes.  Consider too how your design decisions and considerations today may change in the future.  One common example of this is applications that hard-code dependencies on local system resources like the file system, local memory (session, cache, global collections), and local services like email.  When the application needs to scale out to multiple front-end machines, problems ensue.  Loosely coupling these resources together would make implementing a webfarm- or cloud-optimized version of these services trivial, but thousands of new statements gluing implementations together can take a long time to fix.

One last thing to think about, if you actually do search your code for new, is how many duplicate lines you find.  Remember the Don’t Repeat Yourself (DRY) and Single Responsibility (SRP) principles.  If you’re instantiating the same class in the same way in more than one place in your code (e.g. 10 places where you new up a new SqlConnection), that’s a DRY violation.  If you have ten different classes that all do some kind of work, AND need to know how to create a SqlConnection, that’s an SRP violation.  Knowledge of how to talk to the database should be in only one location, the responsibility of a single class.  The same is true for any other resource that you find you’re commonly instantiating in many different classes.  The exceptions here would be low-level intrinsics like strings, datetimes, and things like exceptions that generally are created only in exceptional cases.

Moving Forward

Learn to look for new in your code and in code reviews.  Question whether it’s appropriate when you see it.  Work on pushing the responsibility of choosing which classes your code will work with into as few classes as possible, and see if your code doesn’t start to become more loosely coupled and easier to maintain as a result.

27 Comments

  • Erik said

    <p>Great post.  While considering new carefully is a practice I follow, it's sometimes hard to explain that to people who haven't had the "aha" moment about the significance of it.  Your "new is glue" is both a good description and easy to remember.</p>

  • Jonathan Allen said

    <p></p>

    <p>What a horrible post. This reminds me of the same<br>muddle-headed thinking that got a generation of Java developers to be terrified<br>of the new keyword. </p>

    <p> </p>

    <p>Before you go down this road any further, at least finish<br>the code sample. As it stands, your new code does absolutely nothing. You still<br>need to create the adapter around SmtpClient and MailMessage that makes it<br>adhere to the IEmailClient interface. Once you do that, all those new<br>statements you were afraid of will pop right back into existence.</p>

    <p> </p>

    <p>If this is for “decoupling”, where are the alternate<br>implementations? How do you know your IEmailClient is actually an appropriate<br>interface if you have tried it? Are you even decoupling in the right place? Perhaps<br>SmtpClient is rock solid and what you really need is different versions of SomeService.GetBody.</p>

    <p> </p>

    <p>And since someone is bound to say, no this does not make<br>the code more testable. The GetBody can be unit tested, but no test of DoStuff<br>is meaningful unless you actually send an email.</p>

    <p> </p>

    <p>In short, this style of programming only giving the<br>illusion of decoupling. True decoupling requires careful design work with a<br>deep understand of what you are trying to decouple and why you need to do it. </p>

    <p></p>

  • Seth Petry-Johnson said

    <p>"...no test of DoStuff is meaningful unless you actually send an email".</p>

    <p>I disagree. A unit test of this code would inject some sort of "fake" [mock/stub/whatever] implementation of IEmailClient. The DoStuff() method would fire, and the test could assert that the proper values were passed along to SendHtmlEmail. THAT'S ALL YOU NEED TO TEST; as long as the correct values are passed, this service is correctly interacting with the email component.</p>

    <p>I agree that eventually we need to test actual email delivery. There should be an integration test of each "real" implementation of IEmailClient that handles that. Using interfaces allows the rest of the tests to assume that the email component is working and focus only on their interactions with it, not the side effects of doing so.</p>

  • Steve Smith said

    <p>Thanks for your feedback.  I'm not a Java developer, and the ones I know don't seem to have an irrational phobia of new, so I can't readily respond to that criticism.  It's true that the above code sample doesn't show the (trivial) implementation of IEmailClient that now houses the code with the instantiation logic in it.  That code of course will still have new keywords in it, but it should be the only code in the entire application that is concerned with instantiating SmtpClient(), as opposed to probably a number of locations in the previous implementation that needed to do so.  Hence, it's better from a DRY and SRP point of view.  It's also possible this implementation could be placed in a separate package, such an an Infrastructure assembly, so that it's not requiring any core business services to depend on networking implementations.</p>

    <p>Where are the alternate implementations?  I don't necessarily need them yet.  One that I have written for a similar application replaces calls to SmtpClient with calls to Bus.Send() and queues up messages using a message bus.  And of course there are on-the-fly implementations as Mocks that are used in testing.  It was implied, though I should have probably added some comments to this effect, that the DoStuff() method did more than just send an email.  I'll edit the sample to reflect this.  Given there is real work being done there that might need tested, the testability argument is certainly a valid one, IMHO.</p>

    <p>Let me know, if you don't mind, why this style of programming provides only the illusion of decoupling.  That says to me that, it looks like it's decoupled, but really it's tightly coupled.  So, show me how the resulting code is, in fact, tightly coupled.<br></p>

  • ferventcoder said

    <p>Not going to disagree with everything you said, just the piece below:</p>

    <p>"And since someone is bound to say, no this does not make<br>the code more testable. The GetBody can be unit tested, but no test of DoStuff<br>is meaningful unless you actually send an email."</p>

    <p>public void DoStuff(User user) { <br> string subject = "Test Subject"; <br> string bodyHtml = GetBody(user); <br> _emailClient.SendHtmlEmail("noreply@whatever.com", user.EmailAddress, subject, bodyHtml); <br>}</p>

    <p>This is where I disagree. Look at all of that behaviors, settings, etc in that can be verified. If you mock out IEmailClient you can verify who the email is from in one observation (test if you will), the subject in another observation, and who the email is to in another observation.  You can also start down the route of what should this method do if the user doesn't have an email address. What if the system isn't sending emails in HTML, what do you do then?  </p>

    <p>What if get body returns nothing, what do you do then? If you shift the GetBody function to its own separate class (and interface, say IHtmlConverter), you can create a contract and test that piece. That's at least three observations, one for when IHtmlConverter.GetBody() returns nothing, one for when it returns good stuff, and one for when the call throws an error.</p>

    <p>Having good separation and mocking allows you to easily test different scenarios that would take a lot of setup otherwise. And if you could imagine all of the work you would do manually to go through the debugger and make these tests, in less time you could have a regression suite.</p>

  • jarrettmeyer said

    <p>Great advice. You may take this so far as to say that all static references are glue, just like DateTime.Now, DependencyResolver.Current, etc. Look at the IL that gets generated: new is just another static method on the class.</p>

    <p>Keeping with the metaphor, some glue is 10,000 year epoxy and some glue is rubber cement. You can write test setup code that makes DependencyResolver.Current.GetService&lt;t&gt;() return a mock and write expectations against that mock. But that's a bit of a pain, and often results in a high test : production code ratio. If you use HttpContext.Current, you had better plan on running an in-memory web instance. It can be done, but it's another pain point. And if you use "new MyDataProvider(connectionString)", you can forget about mocking away anything at all.&lt;/t&gt;</p>

  • dotnetchris said

    <p>Dependencies to DateTime.Now are indeed insidious. The way I solve that dependency</p>

    <p>MyFunc(DateTime? timeOrUtcNow = null)<br>{<br>if(!timeOrUtcNow.HasValue) timeOrUtcNow =  DateTime.UtcNow;<br>}</p>

    <p>I'd really like to see .NET get some kind of operator like</p>

    <p>timeOrUtcNow ?=  DateTime.UtcNow;<br>timeOrUtcNow ??=  DateTime.UtcNow;</p>

    <p>Etc.</p>

  • Matt Aybara said

    <p>I understand decoupling. I don't understand how using "new" is anything other than tangentially related to the concept. I think your example would have helped more to explain/illustrate decoupling if you had created an IMessage that was sent to an IMessagingService that would send then chose how to send the message. Then you could have shown an implementation for email, twitter, sms, etc. that takes an IMessage and sends it.<br></p>

  • Matt Aybara said

    <p>It is a matter of the degree of tightly-coupled-ness. No, you are not tied to a specific implementation of an email client, but you are tightly coupled to the type of messaging service, email.</p>

  • Steve Smith said

    <p>Why not just use an interface where it matters (e.g. where the date is used as a condition of behavior)?  I frequently employ ICalendar or IDateTime interfaces for this purpose, or simply write the code in question so that a DateTime is provided as a parameter, if that's an option.</p>

    <p>I think this is the post you're referring to, too: Insidious Dependencies - <a href="http://ardalis.com/insidious-dependencies" rel="nofollow">http://ardalis.com/insidious-d...</a></p>

  • Steve Smith said

    <p>I'll grant you that, though that's a design decision on my part (in terms of what interface I choose to define).  And, I'm still able to, for instance, defer the sending of the email by using a message queue or similar in front of it using this approach, as opposed to synchronously talking to an SMTP server in the method in question, which I think is an important benefit (since I've frequently taken advantage of this separation in real apps).</p>

  • Steve Smith said

    <p>Hi Matt,<br>  That, too, sounds like a great, albeit more involved, example.  I went with the simpler one to keep the post and the example short and simple, and also because I do believe it illustrates the issue.  Even for something as specific as sending an email (not an arbitrary message, but an email), eliminating the use of new (or a static method call) in the client code (the code that needs the email sending functionality) is a big win in terms of keeping the code loosely coupled.  And, perhaps like you, most developers in my experience don't even think about this in simple cases like this, even if they do for less simple scenarios.  I'm trying, with this post and the mnemonic "new is glue" to get a larger number of developers to give this more thought before they instantiate objects throughout their codebase without considering the consequences.</p>

  • Ron C. said

    <p>I'd like to disagree that this style of coding results in code that is "more loosely coupled and easier to maintain".   In the last two or three years, I've seen a tendency to overdose on buzzword-laden techniques like design pattern, loose coupling, inversion of control, dependency injection, abstraction layer, etc.   The result: layers upon layers of convoluted abstraction, configured with layers upon layers of convoluted XML.   The resulting application is so abstracted that anyone other than the original development team needs a 6-9 month learning curve before they have any hope of maintaining anything, and no field tech. has a snowball's chance of getting anything configured in the field.  Of course, if your goal is to create a permanent gig for yourself, have at it!   Those class factories aren't going to write themselves ...</p>

  • Steve Smith said

    <p>Hi Ron,<br>  Where's the XML in this?  And why do you think this needs to become a mess to understand?  It's quite straightforward, in my experience, to keep things organized while still avoiding tight coupling everywhere (though of course it can be the case that things get out of hand and are not organized, no question).  Are you coming from a background that uses XML to configure containers (e.g. Spring) perhaps?  Most .NET containers use conventions for most of their heavy lifting and require just a few lines of code for the rest (where "a few" varies with the size of the application).  Just curious to know where you're coming from, since I'm sure others share your experience, though I do not.</p>

  • Stacy said

    <p>Moving to interfaces and with specific implementations like this is great when you have multiple use cases, or when "refactoring" to accommodate a new use case. Blindly avoiding the "new" and introducing interfaces everywhere should get you fired. </p>

  • tom tomsen said

    <p>I like your post, especially the title: "new is glue". i guess, i'll mumble it every time i write 'new' in the future. thanks :) </p>

  • Anonymous Coward said

    <p> My guess is that "new" is OK as long as you consistently program to interfaces. Swapping "new" for injection is easy, if there's a well defined interface that the new-ed object implements, and the result of "new" is always assigned to an interface, not a concrete type. Extracting an interface might be difficult at times, if the new-ed object's type wasn't thought of implementing a well-specified interface in the first place.</p>

  • Steve Smith said

    <p>You shouldn't blindly use interfaces everywhere to avoid new - agreed.  You should *think* about the coupling you're introducing when you use new, and make a decision about whether it's acceptable.  Also, not writing automated tests of your code should probably get you fired as well, and once you need to call your method both from a test and from the UI, in one case doing real work and in another not, you have your two use cases that necessitate adding an interface.</p>

  • Ron C. said

    <p>The XML comes into play during the next step in loose coupling - making the application more "flexible" by being able to defer what get coupled until run-time.   This means either relying on reflection to decide what gets put together, or configuration by means of a config file, or rows in a database table (metadata).    My background included just such a .NET product.   Dependencies were determined at run-time by nine XML .config files, two of which used a proprietary (barely-documented) schema, and were over 100k in size. (This doesn't include web.config, which was also huge).   It generally took about a year to get a new client deployed.</p>

    <p>My primary opposition is to the idea that "violations" of "principles" like DRY or SRP need to be eradicated for software to be considered "good".  Sometimes you instantiate the same class the same way 10 times because it's a well-written, basic class that can be cleanly reused in ways easy to understand.   Requiring that all these uses be moved to a new, common location means a developer has to look in one more place to learn how a particular piece of code works.    As the application grows, this new location gets used more and more, and then needs to move to it's own single-use location.  These new locations often get moved to new assemblies, so now a developer has to learn the build process to know where to look.  Eventually, it can take days to find where the actual call to something like SqlConnection is made (especially when the XML comes into play).</p>

  • Steve Smith said

    <p>Clearly, like anything else, one can go too far.  Again, I'm not saying that new is evil - obviously you need it.  But I want people to recognize the coupling it introduces and be OK with that, or else consider using an interface instead *if that would be better*.  All things in moderation, and too much is, by definition, too much. :)</p>

  • dotnetchris said

    <p> No, it's similar, but it's a conditional assignment operator. </p>

    <p>It'd be the short hand for </p>

    <p>if(x == null) { x = RightHandSide; }</p>

    <p>^ there's too many places i type in some fashion imo.</p>

  • Corrie Engelbrecht said

    <p>I believe you're missing the point: Had you made use of something like an IMessage and IMessagingService, that usage would have illustrated decoupling.</p>

    <p>However, your use of new (any of your uses of new in the article), does nothing to illustrate decoupling. It is irrelevant to decoupling.</p>

    <p>Instantiating objects has no causal relationship to tightly coupled code.</p>

    <p>This relationship is what you fail to illustrate in your article, because there is no such relationship.</p>

  • Steve Smith said

    <p>Because you say so?</p>

    <p>I respectfully disagree.  Calling a static method, or newing up a specific class, both couple the calling code to a specific implementation.  I assert this is true on the basis of my experience and the difficulty of writing a test that can test the calling code without the coupled code being invoked.</p>

    <p>I'd be happy to hear why you feel this is not the case, but would ask for more than "because you said so."</p>

  • Corrie Engelbrecht said

    <p>Not because I say so. Because logic and structure says so.</p>

    <p>Just a note: I fully understand what you're asserting.</p>

    <p>Everyone does.</p>

    <p>The missing ingredient is your supporting evidence.</p>

Add a Comment