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.
“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.”
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.
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.
评论：
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.
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 ...
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.
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. :)
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 - http://ardalis.com/insidiou...
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.
You said to avoid new keyword to avoid tight coupling. What if instead of using new keyword, I call UI->BL->DAL as static class (where BL, DAL are static class). Does this also tightly couple it, please make me understand this scenario.
Yes, certainly. This also has a catchy name (I didn't coin) called "static cling" because the use of statics makes unrelated parts of your codebase stick together. Statics with no side effects are fine to call, but those with dependencies on infrastructure (like DAL/Database) can make your code difficult to test and change.
Hi.
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?
Thanks.
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?
I don't have time to code it right now, but you could probably also use a Lazy<t> for this purpose, too.
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.
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).