.NET (Core and Framework)

Colin Angus Mackay23-Jul-06 0:17

23-Jul-06 0:17

Because a constructor must always return a new instance of the object you might like to look at alternatives.

For example: Use the factory pattern. Specifically: use a factory method.

A factory method is one that creates an object but is not a constructor. You might create one like this:

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
}

The rest of the code cannot access the constructor, and must use the CreateMyObj factory method to instantiate the object. The method may return null if the object cannot be created.

Does this help?

Scottish Developers events:
* .NET debugging, tracing and instrumentation by Duncan Edwards Jones and Code Coverage in .NET by Craig Murphy
* Developer Day Scotland: are you interested in speaking or attending?
My: Website | Blog

Giancarlo Trevisan23-Jul-06 19:08

23-Jul-06 19:08

Your factory method technique is valid indeed, however, you hit my question on the mark with the statement:

>>>...a constructor must always return a new instance of the object...

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

Thank-you

Visualize then Realize

Colin Angus Mackay23-Jul-06 19:42

23-Jul-06 19:42

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

No it wouldn't. The purpose of a constructor is to construct an object. If it was able to avoid doing that then the semantics of a constructor would be broken.

Giancarlo Trevisan23-Jul-06 20:07

23-Jul-06 20:07

Yes, we are talking about semantics and at this point about philosophy. I agree that a constructor should construct, and you probably agree that constructors have a behavior of their own in the sense that they are not functions yet return a handle to an instance: keep in mind that a NULL is also an instance.
My consideration is, why not allow constructors that allow ONLY, if necessary, "return null", the semantics would not be crippled yet acquire "selfawareness".

Visualize then Realize

Colin Angus Mackay23-Jul-06 20:15

23-Jul-06 20:15

Giancarlo Trevisan wrote:
keep in mind that a NULL is also an instance

Ummm... No. A null is the absence of a 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".

Returning null from a constructor would cripple the semantics of a constructor. The purpose, and I feel I'm repeating myself here, of a constructor is to construct an object. To do anything otherwise would be to "cripple" the semantics of a constructor.

If you don't want it to actually construct an object there is an existing solution and that is to throw an exception. And in fact that isn't really a solution because the instance will already exist at the point the exception is thrown. It just means that, so long as the exception is thrown out of the constructor, nothing will ever reference the instance.

Giancarlo Trevisan23-Jul-06 20:22

23-Jul-06 20:22

Visualize then Realize

Guffa23-Jul-06 22:44

Guffa

23-Jul-06 22:44

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

If you did allow the constructor to kill the object that is constructed, it would mean that you get an additional way of returning error status, that you have to handle everywhere.

The semantics would actually be crippled, as you could no longer trust that creating an object actually did create an object. You would have to check the reference after each object you create.

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

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

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

---
b { font-weight: normal; }

Giancarlo Trevisan24-Jul-06 2:05

Re: How about a constructor that autodestructs? [modified]

24-Jul-06 2:05

I began the post with a postscriptum and the possibility to raise a System.Exception() (preceeded possibly by a Me.Dispose?): an ApplicationException would be more appropriate. I agree that raising an exception is the correct approach, who better than a class knows if the conditions are right to instantiate an object: I call this encapsulation.

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

Let's go to an extreme, there is not enough memory to create an object, proper code would still require a reference check. In my view NOT ENOUGH MEMORY is a condition that does not allow object instantiation, I'm just generalizing. 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.

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

Very profound, I add, evolution is applicable even to programming languages and is a consequence of trial and error or, better for humans, a questioning to gain deeper knowledge (my knowledge is probably superficial). I am alluding at a fundamental behavior that in my view would not be crippling but evidently this is not a general consensus.

Smile | :)

Visualize then Realize

Dave Kreskowiak24-Jul-06 2:38

Dave Kreskowiak

24-Jul-06 2:38

Giancarlo Trevisan wrote:
I call this encapsulation.

Not accurate at all. Your "implementation" doesn't encapsulate anything. Your actually trying to give a class the option of not creating itself based on conditions OUTSIDE the class. So, you're not encapsulating anything, but are forcing a class to look outside of its own scope. It must know certain things about the environment its running in. That's quite the opposite of encapsulation.

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.

The factory pattern in the best way to go to maintain that encapsulation. There's nothing that says you can't write multiple factories, each dealing with a specific set of requirements, to create the same class.

Dave Kreskowiak
Microsoft MVP - Visual Basic

-- modified at 8:38 Monday 24th July, 2006

Re: How about a constructor that autodestructs? [modified]

Giancarlo Trevisan24-Jul-06 2:57

24-Jul-06 2:57

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.

Did it cross your mind that the temperature is a constructor parameter? And that instead of temperature I could pass the class constructor a nice reference of the Environment? Are you alluding that the Environemnt should know better than MythicalFooCreature if it can grow? It's a point of view, your classes are isolated, I tend to see mine as living in a commmunity. I encapsulate within the constructor the birth/death behavior: this is what I call selfawareness.

And I do agree that Factoring is the best solution. Smile | :)

Visualize then Realize

-- modified at 9:06 Monday 24th July, 2006

Re: How about a constructor that autodestructs? [modified]

Dave Kreskowiak24-Jul-06 6:44

Dave Kreskowiak

24-Jul-06 6:44

Giancarlo Trevisan wrote:
Did it cross your mind that the temperature is a constructor parameter?

Yes, it did!

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

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

Example - Your class, written under the .NET Framework on Windows XP, needs certain things to exist before it can construct itself. Great! You pass in your Environment and your class constructs itself. Wonderful!! Now, use the exact some code under Mono on a Linux box. But, the Environment class under Mono doesn't expose the same information that it does under Windows. Your class constructor now fails because it can't get what it expects, even though the code would run perfectly! Now what???

That's what the factory pattern is for! The factory is responsible for checking to see if it is OK to construct the class. Is it wise to put an entire automotive assembly plant in every car so it can build itself?

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

Dave Kreskowiak
Microsoft MVP - Visual Basic

Giancarlo Trevisan24-Jul-06 19:06

24-Jul-06 19:06

Dave,

as class builders we model the problem at hand, I consider modelling a wonderful art.

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?

I can reply very simply: the Environment conditions the MythicalFooCreature during its life.

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???

You are right! You can try to instantiate a MythicalFooCreature in a hostile Environment, it would probably not live, and the constructor would be the first to know. (Mind you, I don't mean to undermine Mono nor Linux)

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.

Hm, this is a rather strong assertion, we could really debate about this.

At any rate, I do not like to reinvent wheels, and if I do I'll use inheritance. My post questioned: why not have a Constructor that in some cases DOES NOT do its job, construct, but simply does nothing? What are the implications? However we model this necessity at the end the instance should not be there. So there, we create then destroy, that's when my minimalist nature came in, and I wrote the post, why not simply "cut short" from within the constructor?

I'm investigating the effect of Dispose as implied in the pseudocode below, this would solve the need at hand:

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

Maybe the dispose is not necessary since throwing an exception within a constructor does it automatically.

-- modified at 1:19 Tuesday 25th July, 2006

Colin Angus Mackay24-Jul-06 2:38

24-Jul-06 2:38

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

No, proper coding would require that the out of memory exception is handled.

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.

You can't do both. Either raise the exception in the constructor, or use a Factory Pattern.

If an exception is thrown to something outside the constructor it no longer matters what the constructor would have returned because the garbage collector will get it before anything else can get a reference to it.

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.

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.

Giancarlo Trevisan24-Jul-06 3:02