.NET (Core and Framework)

public class MyObj
{
    // private constructor - only things within the class can call it.
    private MyObj(/* parameters go here */)
    {
        // Do initialisation here.
    }
 
    public static CreateMyObj(/* parameters go here */)
    {
        MyObj result = null;
       
        // Check the parameters here
 
        if (parametersAreOkay)
        {
            result = new MyObj(/* parameters go here */);
        }
        return result;
    }
 
    // Rest of class goes here
}

Giancarlo Trevisan wrote:

It would be nice if constructors behaved as functions, then "return null" would be clear and clean. Something to think about.

Giancarlo Trevisan wrote:

keep in mind that a NULL is also an instance

Giancarlo Trevisan wrote:

My consideration is, why not allow constructors that allow ONLY, if necessary, "return null", the semantics would not be crippled yet acquire "selfawareness".

Giancarlo Trevisan wrote:

My consideration is, why not allow constructors that allow ONLY, if necessary, "return null", the semantics would not be crippled yet acquire "selfawareness".

StringBuilder sb = new StringBuilder();<br />
if (sb == null) throw new ApplicationException("Object creation failed.");

Guffa wrote:

In practice this would mean that everyone would just write code to check the reference and throw an exception, to get the behaviour that we already have (but with less information about what caused the error):

Guffa wrote:

The power of a programming language is not only what you can do, but also what you can't do.

Giancarlo Trevisan wrote:

I call this encapsulation.

Dave Kreskowiak wrote:

A properly designed class shouldn't care about ANYTHING outside of its own scope. All it should need is proper parameters to construct itself. If it needed to look outside of itself, that would destroy its ability to be reused in non-similar situations.

Giancarlo Trevisan wrote:

Did it cross your mind that the temperature is a constructor parameter?

Giancarlo Trevisan wrote:

And that instead of temperature I could pass the class constructor a nice reference of the Environment?

Dave Kreskowiak wrote:

Beyond the constructor, does the Environment have ANYTHING to do with what's inside the class?? Nope. So why should it care?

Dave Kreskowiak wrote:

Your class constructor now fails because it can't get what it expects, even though the code would run perfectly! Now what???

Dave Kreskowiak wrote:

The class code should care NOTHING about what's going on outside of it. The class is, literally, it's own little world.

Class MythicalFooCreature<br />
  Public Sub New(temp)<br />
    If temp < 32 Then<br />
      Me.Dispose()<br />
      Throw System.Exception("Too cold")<br />
    End If<br />
  End Sub<br />
End Class

Giancarlo Trevisan wrote:

Let's go to an extreme, there is not enough memory to create an object, proper code would still require a reference check

Giancarlo Trevisan wrote:

Give you an example, class MythicalFooCreature can't be instantiated if the temperature is below 32F, in my view the constructor should raise an exception and return a null reference.

Giancarlo Trevisan wrote:

I am alluding at a fundamental behavior that in my view would not be crippling but evidently this is not a general consensus.

Colin Angus Mackay wrote:

It wouldn't be crippling per se, but it would change the semantics. There already exists a semantic equivalent for what you want to do over the responsibility of a basic constructor that you can use (i.e. The Factory Pattern) so why reinvent the wheel.