Skip to main content
Software Engineering

Return to Answer

added 1143 characters in body
Source Link
Flater
Flater
  • 56.3k
  • 8
  • 106
  • 157

No.

Well, I can't cover every possible language in existence, but no it is not a common feature or design principle in any language I've ever heard of. Except Javascript, but JS is a fine example of giving developers much more access than good reason would dictate. "It can be done in JS" is not equivalent to "It is a good idea to do this in JS".

But there are two thoughts that come to mind here:

I don't quite see how you can't just overwrite one object with another. Unless you're using readonly (or similar write-protecting features), but then the solution is to stop blocking the ability to overwrite one object with another.

right now in my specific case

This is just a tip, because I suspect you're trying to approach this in a way that I used to approach development back when I got started. With hindsight, I would tell my younger self:

One thing you learn as a developer is that overfitting, i.e. trying to really custom tailor something to your particular situation, is less effective, because you've spent time creating and now have something that is so uniquely fit for the job at hand, that it has no purpose in any other scenario.

Conformity tends to win the day in the long run. Stick to good practice and perfectly acceptable code, in this case instantiating a new object, rather than trying to reinvent the constructor and how it works.

While it may not be the ultimate min-max for your current situation, it is a very versatile approach which will apply in many scenarios, and therefore you will over time use it more and more and gain much more confidence experience with it.
This is much more useful to you as a developer, as opposed to only having built highly custom implementations that do not carry over into your future experiences.

No. But there are two thoughts that come to mind here:

I don't quite see how you can't just overwrite one object with another. Unless you're using readonly (or similar write-protecting features), but then the solution is to stop blocking the ability to overwrite one object with another.

No.

Well, I can't cover every possible language in existence, but no it is not a common feature or design principle in any language I've ever heard of. Except Javascript, but JS is a fine example of giving developers much more access than good reason would dictate. "It can be done in JS" is not equivalent to "It is a good idea to do this in JS".

But there are two thoughts that come to mind here:

I don't quite see how you can't just overwrite one object with another. Unless you're using readonly (or similar write-protecting features), but then the solution is to stop blocking the ability to overwrite one object with another.

right now in my specific case

This is just a tip, because I suspect you're trying to approach this in a way that I used to approach development back when I got started. With hindsight, I would tell my younger self:

One thing you learn as a developer is that overfitting, i.e. trying to really custom tailor something to your particular situation, is less effective, because you've spent time creating and now have something that is so uniquely fit for the job at hand, that it has no purpose in any other scenario.

Conformity tends to win the day in the long run. Stick to good practice and perfectly acceptable code, in this case instantiating a new object, rather than trying to reinvent the constructor and how it works.

While it may not be the ultimate min-max for your current situation, it is a very versatile approach which will apply in many scenarios, and therefore you will over time use it more and more and gain much more confidence experience with it.
This is much more useful to you as a developer, as opposed to only having built highly custom implementations that do not carry over into your future experiences.

Source Link
Flater
Flater
  • 56.3k
  • 8
  • 106
  • 157

No. But there are two thoughts that come to mind here:

1. It's easily worked around using a method

public class Foo
{
    public Foo(int x, string y)
    {
        MyLogic(x,y);
    }

    public void MyLogic(int x, string y)
    {
        // Whatever constructor logic you would've had
    }
}

However, this does not play nicely with readonly fields.

I would expect that your intended purpose very much takes into account that all of your class fields/properties should be "resettable", since you want to "reset" your object, so you wouldn't be using any readonly fields to begin with.

2. Why would you want to?

This is the bigger issue for me. You seem to understand that a constructor is an initialization algorithm and sets the object to its initial state. That is correct.

But then why are you invested in "resetting" an existing object, when you can't find a way to do so; while you could just as easily just create a new object and discard the old one?

In essence, what's wrong with this code instead:

var person = new PersonModel("John", "Doe");

// We want to change our person now
person = new PersonModel("Jane", "Doe");

I'm writing code and I have a case where I have reusable objects (data objects in collection) and being able to update the object through the constructor parameters would be an easy way to update the data object for me for right now in my specific case.

I don't quite see how you can't just overwrite one object with another. Unless you're using readonly (or similar write-protecting features), but then the solution is to stop blocking the ability to overwrite one object with another.