New is Glue

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

Since originally publishing this article, Hollywood produced an entire movie centered on this principle, in which the LEGO bad-guy was trying to glue pieces together. Don’t be that guy.

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:

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:

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

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.


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.

  • Erik

    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.

  • Jonathan Allen

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


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


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


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


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

  • Seth Petry-Johnson

    “…no test of DoStuff is meaningful unless you actually send an email”.

    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.

    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.

  • Steve Smith

    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.

    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.

    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.

  • ferventcoder

    Not going to disagree with everything you said, just the piece below:

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

    public void DoStuff(User user) {
    string subject = “Test Subject”;
    string bodyHtml = GetBody(user);
    _emailClient.SendHtmlEmail(“”, user.EmailAddress, subject, bodyHtml);

    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?  

    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.

    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.

  • jarrettmeyer

    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.

    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<t>() 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.</t>

  • dotnetchris

    Dependencies to DateTime.Now are indeed insidious. The way I solve that dependency

    MyFunc(DateTime? timeOrUtcNow = null)
    if(!timeOrUtcNow.HasValue) timeOrUtcNow =  DateTime.UtcNow;

    I’d really like to see .NET get some kind of operator like

    timeOrUtcNow ?=  DateTime.UtcNow;
    timeOrUtcNow ??=  DateTime.UtcNow;


  • Michael Perryman

    Are you referring to the null coalescing operator?  (??)

  • Matt Aybara

    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.

  • Matt Aybara

    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.

  • Steve Smith

    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.

    I think this is the post you’re referring to, too: Insidious Dependencies –

  • Steve Smith

    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).

  • Steve Smith

    Hi Matt,
      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.

  • Ron C.

    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 …

  • Steve Smith

    Hi Ron,
      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.

  • Stacy

    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.

  • tom tomsen

    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 🙂

  • Anonymous Coward

     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.

  • Steve Smith

    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.

  • Ron C.

    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.

    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).

  • Steve Smith

    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. 🙂

  • dotnetchris

     No, it’s similar, but it’s a conditional assignment operator.

    It’d be the short hand for

    if(x == null) { x = RightHandSide; }

    ^ there’s too many places i type in some fashion imo.

  • Corrie Engelbrecht

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

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

    Instantiating objects has no causal relationship to tightly coupled code.

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

  • Steve Smith

    Because you say so?

    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.

    I’d be happy to hear why you feel this is not the case, but would ask for more than “because you said so.”

  • Corrie Engelbrecht

    Not because I say so. Because logic and structure says so.

    Just a note: I fully understand what you’re asserting.

    Everyone does.

    The missing ingredient is your supporting evidence.

  • Mac Cosmetics Cheap
  • Hey Steve,

    Saw your tweet about revisiting that article. I’ll have to agree with you. new is glue.

    But just like everything, glue isn’t necessarily bad. It’s all about picking what you glue together. I do new lists, exceptions, MVC action results, etc. Why? Because it’s the right thing to do and decoupling at that level would not bring anything to the table. Not even testability.

    Repositories? DbContext? Email Sender? Yeah no. I’m not gluing those. What if I swap my SmtpClient for SendGrid or ? Well… all my tests will break and are not guaranteed to be reimplemented properly.

    Still a great article 4 years later.


    • ardalis

      Thanks! Yes, I agree completely that ‘new’ isn’t something to be avoided, just something to be mindful about. By all means instantiate value objects and non-infrastructure types directly. Don’t add abstraction for abstraction’s sake. But do remember the coupling you’re introducing when you do new up an infrastructure type…


  • Hi.

    From what I comprehend, if I was to UML this, your advice for us is to be aware of what type of class association we’re creating. You’re forwarding aggregation. Please, feel free to correct me if I’m wrong. While it’s true that aggregation frees the receiving class from instance management of other classes instances, composition and new go hand in hand. Is this also wrong?


    • ardalis

      My only point here is to recognize that every time you use ‘new’ within a method (or class), you are coupling your code to a specific implementation type. That may be, and often is, perfectly acceptable. It’s no different than if you were calling a static method, in terms of the coupling effect. Coupling isn’t *bad*, per se, but it should be managed. Unnecessary tight coupling causes problems with testability and ultimately maintainability in applications. Thus, it’s worth putting at least a little bit of thought into how much coupling you want between your classes, and where you want decisions to be made about which classes couple to which implementations.

      If you follow the Dependency Inversion Principle, you’re likely to have a loosely coupled application where decisions about which implementations to use are made centrally, not scattered throughout the codebase. See my training classes on SOLID and N-Tier applications for more on this topic:

      • I think this needs more clarity, for me anyway.

        I follow that the coupling level is dictated by the OOP design of my app, not by the API design of my app, as you seem to suggest. If I make a design decision to create a composition type association between classes, it means I had normalized my types, some of them would always be part of a composition.

        As a consequence, no aggregation type association could replace the composition type association among classes, for a variety of reasons, the composition source type having no business existing on its own, being one of them.

        • ardalis

          I’m mainly referring to types that are instantiated within methods in order to perform logic relevant to that method. The ‘new’ keyword is less a concern (to me, at least) for how you’ve designed your model and the entities that have property relationships to one another. In my designs, such entities are POCOs that can be instantiated anywhere without side effects, so the effect of using ‘new’ on them isn’t a problem. It’s when you’re in the middle of some operation that has no side effects and you decide you need some data so you use new to create a dbConnection, which in its constructor tries to open a connection to a database, that you’ve caused a major coupling problem. How then will you test that method, without having a database? That’s more of the issue being considered here.

          • In some way, I see it as trying to avoid the inevitable. No matter how many levels more I put off tight coupling, there will be a lower next level where my app can’t be tested without having a database or a mock-up data source.

            For me, this is a battle among testing and API design against OOP design for my app. I simplify testing and tighten API by sacrificing OOP clarity. When is the trade off worth it? Are there general guidelines or it’s a case by case analysis?

          • ardalis

            Do you have a Pluralsight subscription? If not, send me an email via the contact form and I will send you a free 30-day pass. Watch the DDD Fundamentals course I did with Julie Lerman. Look at the sample application there. In this architecture, OOP and testing are not sacrificed. Implementation classes are placed in a specific project that can be tested using integration tests. Business and domain logic goes into another project that can be extensively tested with unit tests, and which has no dependencies on infrastructure concerns or implementation details. The general guideline to follow, once you have this architecture in place, is to push as much of your business logic into the Core project, and only put things into the Infrastructure project that have dependencies on infrastructure concerns (databases, files, networking, etc).

          • Thanks for the offer.

            You mention two classes of classes: infrastructure and business. It doesn’t change the concern: you can tightly couple classes both in infrastructure and in business. And, to be clear, I don’t mean across infrastructure and business, but either in infrastructure or in business.

            So, you can have tightly coupled classes in infrastructure. You create another class of classes to resolve the problem? No, the problem does not have anything with the administrative aspect of the code, but with the OOP aspect of the design.

            I guess I’m saying is that by keeping the app code closer to the initial OOP design, including tightly coupled class association, this has more positive advantages in app management rather than messing the OOP design in order to get a safer or tighter API.

          • ardalis

            I’m not sure I follow your concern at this point. You can see an example of the kind of architecture I’m talking about here:

            If you feel this architecture is “messing with” the OOP design or is otherwise making sacrifices that you think aren’t worthwhile, let me know (here or via an issue in that repo). Thanks!

          • OK, thank you also for the links and for the replies.



    I landed here again after reading the excellent .Net C# tutorial.

    I saw this code for the Orders property (right) and I didn’t really liked it. I modified it like this (left): I moved the Orders property initialization in the constructor. Any reason I shouldn’t?


    • Eric

      This isn’t really related to the article, but either version would *usually* be fine. There is a difference (with possible performance implications) in how the two versions work. Your code on the left creates the _orders collection immediately when the Customer instance is created, regardless of whether the Orders property will ever be accessed. The code on the right is an example of lazy instantiation, where the _ordersView collection isn’t created until the first time the Orders property is accessed, and if Orders is never accessed then the collection is never created.

      • Yes, it’s not related to the article, I’m sorry if it’s out of place. I can’t help but notice that the lazy instantiation is burdened by a mandatory check on each access. It also adds a new member. I’d say it’s premature optimization, the lists are not populated at this point, so there’s not really a memory penalty. I’d also say the code smells. Is there something I’m getting wrong?

        • ardalis

          I don’t have time to code it right now, but you could probably also use a Lazy for this purpose, too.