The “new” smell

Currently I am finishing reading the book Dependency Injection in .NET from Mark Seemann. The really good thing about this book is, that it assigns names to DI patterns as well as anti-patterns. My own reflection on the topics covered in the book brought up a simple (maybe provoking) thesis:

Occurrences of the new operator most likely have a smell.

Everytime I “new” up an instance I create a very strong dependency upon a concrete implementation. Although this is common knowledge and nothing special in itself, it is practiced day by day – producing tightly coupled code. This is why I consider occurrences of the new operator a code smell.

Dependency injection is a well established technique that helps producing loosely coupled code. Since DI and IoC are (imho) advanced concepts, differently skilled developers (which you almost always find in a team) may or may not be familiar with those concepts. So what I was looking for is a rule-of-thumb that supports the ultimate goal of getting a team of developers with very different skills write loosely coupled code (and maybe not even recognizing it at first).
I am almost sure I found this rule, because it is so damn simple:

Do not use the new operator.

The best thing about this rule is that I can make my static code analysis recognize and find it. Having set up a CI server performing static code analysis for me, the only work left is analyzing the findings.
I can then discuss the findings in peer reviews, refine my rules when using the “new” operator is indeed a good thing and start collecting statistical data on problem “hot spots” which I can use to find and develop skill improvement strategies (e.g. trainings).
But one of the most important advantages I see when applying this in practice is the boost in communication on a fundamental quality criterium of software systems that often enough decides on project success – a loosely coupled modular design.

In conclusion I can say that the rule itself is indeed very restrictive, since there are several situations where using the new operator is perfectly legal, but starting off with this simple rule will all by itself motivate group discussion and contribute to a common understanding. And that’s what I had in mind.

I would really appreciate when you leave a comment and describe your perspective. Do you consider occurrences of the new operator a smell as well or do you totally disagree with me? I am really interested in your opinion!

6 thoughts on “The “new” smell

  1. This is surprising. Your project seems to be largely free of DTOs, entities and other kinds of such data structures. I have never come across such a project myself.

    1. Hi tobi,
      thanks for your feedback. You are perfectly right coming up with examples of plain data structures. Indeed there may be cases where creating instances of those in an arbitrary place in your code can be considered harmless (e.g. creating a DateTimeOffset). But regarding DTOs or similar data structures, I would follow a clean and stereotype DI approach and inject abstract factories (using constructor injection) that can create these instances into objects that need to create such instances. As for DTOs I can also imagine that there is some type of mapping involved, maybe using 3rd party libraries like AutoMapper, so often a simple ‘new’ may seem enough at first glance but it does not evolve very well.

  2. Florian, I thought of the most simple things like:

    class CreditRating {
    string accountNo;
    CreditRating rating;
    string ratingReason;

    and a service like this:

    interface IRatingService { CreditRating GetRating(…); }

    In this case I’d never forsee the need to use anything other than a plain DTO. No mocking necessary because I can set arbitrary values on the DTO class.

    Different example: dataContext.Customers.InsertOnSubmit(new Customer() { … });

    1. Tobi,

      what is happening with our discussion is exactly what I initially wanted to achieve: developers talking about the situations they consider “newing” up an instance perfectly legal. I didn’t say using the new operator is bad in every case (it’s just worth analyzing it), but I started off with a provoking thesis and a (obviously) very restrictive rule for a simple reason: every single new will be discussed. In my opinion, this is a very good strategy to make a team communicate, develop a common understanding and find team conventions related to object creation and lifetime management. If a team doesn’t need that or already has it, my thoughts don’t match well. But in other cases, I believe this can be handy.

  3. Actually, I am surprised to find myself to agree 😉

    Maybe a follow up blog post in a few weeks on how it went would be interesting!

    PS: You can get rid of the “password” on this form. Just add a hidden input called “nickname” and discard any posts which have a non-empty value in it 😉 Always works.

    1. Unfortunately I cannot come up with real life experience in a follow-up post, since my post was not motivated by real life problems. When I see the need to exercise it in a project, I definitely will, but for the moment, I cannot serve with real life experience.
      Nevertheless, I consider posting some additional thoughts on this topic, making it more concrete by providing examples and collecting feedback on them. I believe there is a at least a common sense across many developers concerning this topic. So maybe we can derive a set of less restrictive guidelines.
      Though I believe the “Do not use new” rule with the single exception for using it at the “composition root” will work very well.

Leave a Reply

Your email address will not be published. Required fields are marked *