C＃当已经实现了getter时，对象的setter的目的是什么？

Question

If there's a class which has a getter for an object, when the getter returns the object you can modify this object outside of its own class container, and this changes will be reflected when you read the object later with the getter again; so, I can't see the goal to set a setter for the object when the getter let me to read and modify the object as well.

Example: You have a class called CashRegister and this class has an object called queue, if you read queue by means of a CashRegister's getter you can modify queue from the MainClass and the next time you invoke the CashRegister's getter the modifications previously made in MainClass will be present. By the way CLI.PrintAndJump() prints the content of a queue.

class MainClass
{
    static void Main(string[] args)
    {
        Queue<int> tmpQueue, tmpQueue2;
        CashRegister aCashRegister = new CashRegister();

        tmpQueue = aCashRegister.GetCoinValues();
        CLI.PrintAndJump(tmpQueue);

        tmpQueue.Enqueue(10);

        tmpQueue2 = aCashRegister.GetCoinValues();
        CLI.PrintAndJump(tmpQueue2);
    }
}

class CashRegister
{
    Queue<int> coinValues = new Queue<int>(1);

    public Queue<int> GetCoinValues()
    {
        return (coinValues);
    }
}

Output:

1

1, 10

In a nutshell, if you need to modify the object queue, you don't need to set a setter for it (Is this method a good practice?), but what if I want the object to remain immutable?

Thanks.

Answer 1

In the context of C#, we typically talk about "setter" and "getter" methods in relation to a property, so it's kind of odd that your code example doesn't include any properties. But, let's ignore that for a moment, and assume that you might have a corresponding SetCoinValues() method.

The reason for such a method would be if you want to replace the entire Queue<int> object. There is a difference between modifying the Queue<int> object itself, which you can do with only a getter method, and replacing the Queue<int> object with a whole new one, which would require a setter method.

Why one might want to do this varies. It depends on the exact circumstance. And I think it's less likely one might want to replace a queue object, than say some other collection type (like an array or a list), or some other complex type other than a collection. But it could still happen.

Examples of complex types which are used as property values, or in terms of the non-property scenario, might have both a getter and setter method, include System.Windows.Media.Pen.DashStyle and System.Diagnostics.Process.StartInfo . The DashStyle object itself even has properties for setting and getting complex values, including the Dashes property, which is a collection of Double values.

I mention these to emphasize that this really has nothing at all to do with mutable vs. immutable. Both DashStyle and ProcessStartInfo are mutable types, but we still have properties which reference objects of those types and which have setter methods in addition to a getter.

The question of mutability (which seems to be the emphasis of the other answer ) is a red herring, and will only distract you from what is really going on. The real point is that, even with mutable, complex types, there are times when you want to be able to replace the entire object, rather than modifying the object currently being held. In those cases, you need a setter method, so that you can change the actual reference for the property, instead of modifying the object the property refers to.

Answer 2

First of all, this is C#, not Java. In C#, we do not write getters and setters; we use properties instead. So, GetXyz() methods in C# are usually not getters, and they are very rarely paired with SetXyz() methods. For example, think of ICollection.GetLength() . Once we have established that, let's move on.

Read-write properties are primarily used for immutable values, an example of which are primitives. I hope you understand that you cannot get for example an int , change its value, and expect the value held by the containing object to also change. You have to put it back. And for this you need a writable property. But you have anticipated that, because in your question you are talking about objects.

Primitives are not the only entities that you cannot modify; there exist plenty of immutable struct s and class es that behave the same way. If a property returns to you an object that simply does not offer any methods that you could use to alter its state, the only thing you can do is create a different instance of that object, and put it back in the containing object, for which of course you will need a writable property.

So, writable properties are necessary for writing back immutable entities.

When it comes to mutable objects, you are right, it does not make much sense to have a read-write property, because once you obtain a reference to the mutable object you can mutate it to your heart's content without ever having to "set" it back. For this reason, you will rarely see a setter for a mutable. But it happens some times. Peter Duniho covers an example of this in his answer. (It is mainly done for performance/convenience reasons, and the implied agreement in these cases is that the containing object does not have ownership of the object that is being set into it.)