Reply to: Passing objects to methods then changing the object's state

[BrilloPad]

Why o why are people still doing this and who is teaching these progammers that they are allowed to do this?

Easily the fastest route to a tulipe codebase.

Does my fuggin head in.

</rantOver>

Its deliberate. Obsfucation. The only solution is a good kicking.

[Gentile]

That's not the same effect. You're talking about pass by value, which means a potentially expensive memory copy just to avoid the scenario where the function might change the original data, and wouldn't stop the programmer trying to change the data and spending ages debugging why it wasn't working.

In C++ you pass a constant reference to the object, which means you have limited read-only access to the original object (functions that are marked const), but it's still the original object. Trying to change the object results in a compile error.

The OP's rant was obviously down to spending ages trying to find a bug introduced by some junior programmer. If it had been done in C++, the bug would never have existed because the code wouldn't have compiled.

Thanks for that. It's always good to learn a bit more about the capabilities of other languages.

I don't think there's any way to take a readable/writeable object in C# and temporarily make it read only on the fly in the way you described. The nearest I can think of is implementing an interface in the class that renders desired Properties read only such as:



It still relies on the author of the MangleMyClass method taking ownership of the problem, though. I suspect that the OP's problem is caused by an inexperienced developer that is authoring Methods in a way that allows them to be misused.

[VectraMan]

C# has structs that achieve much the same effect; if 'MyClass' were defined as a struct in my example above (which you could do simply by changing the class keyword to struct), then whether you used the ref keyword or not would affect the outcome.

However, there's a trade-off in terms of memory usage since structs are stored on the Stack rather than on the Managed Heap, and so aren't suitable for .net's Garbage Collection mechanism. In order to benefit from Garbage Collection, you need to rely on developers using Reference Types sensibly.

That's not the same effect. You're talking about pass by value, which means a potentially expensive memory copy just to avoid the scenario where the function might change the original data, and wouldn't stop the programmer trying to change the data and spending ages debugging why it wasn't working.

In C++ you pass a constant reference to the object, which means you have limited read-only access to the original object (functions that are marked const), but it's still the original object. Trying to change the object results in a compile error.

The OP's rant was obviously down to spending ages trying to find a bug introduced by some junior programmer. If it had been done in C++, the bug would never have existed because the code wouldn't have compiled.

[Gentile]

void mangle( MyClass& objectToBeMangled )
{
}

void someOtherFunction( const MyClass& objectNotToBeManged )
{
    mangle( objectNotToBeMangled ); // compile error : cannot convert const MyClass& to MyClass&
}

That's how the professionals do it.

Seriously I find it utterly incomprehensible that the forefathers of Java and C# didn't carry this over from C++, as it makes such a difference to the reliability and maintainability of software when you use const types properly.

C# has structs that achieve much the same effect; if 'MyClass' were defined as a struct in my example above (which you could do simply by changing the class keyword to struct), then whether you used the ref keyword or not would affect the outcome.

However, there's a trade-off in terms of memory usage since structs are stored on the Stack rather than on the Managed Heap, and so aren't suitable for .net's Garbage Collection mechanism. In order to benefit from Garbage Collection, you need to rely on developers using Reference Types sensibly.

[VectraMan]

void mangle( MyClass& objectToBeMangled )
{
}

void someOtherFunction( const MyClass& objectNotToBeManged )
{
    mangle( objectNotToBeMangled ); // compile error : cannot convert const MyClass& to MyClass&
}

That's how the professionals do it.

Seriously I find it utterly incomprehensible that the forefathers of Java and C# didn't carry this over from C++, as it makes such a difference to the reliability and maintainability of software when you use const types properly.

[Gentile]

Surely you mean just passing a reference to an object, and not the object itself?

Surely, Shirley?

The trouble is, with Reference Types (e.g., all custom Classes that inherit from System.Object in C#) you are always passing a reference to the object, whether or not you explicitly state that it is by reference.

i.e., the following code will have identical outcomes whether or not you include the highlighted ref keywords. :

namespace DontChangeTheStateOfReferenceObjectsInPublicMethods
{
    class MyClass
    {
        public int SomeIntProperty { get; set; }
    }

    static class MyStaticClass
    {
        public static void MangleMyClass(ref MyClass someClassToBeMangled)
        {
            someClassToBeMangled.SomeIntProperty = 100; 
            //I don't care what it was when you passed this object in
        }
    }

    public class DoStuff
    {
        MyClass myInstanceOfMyClass = new MyClass { SomeIntProperty = 900 }; 
        //I really want this to still be '900' later!

        public DoStuff()
        {
            MyStaticClass.MangleMyClass(ref myInstanceOfMyClass);
            /* myInstanceOfMyClass will be 100 at this point, and I wont 
               be sure why if I don't have access to the code for MyStaticClass.MangleMyClass */
        }    
    }
}

[hyperD]

Good reading about GOTO statements

Code Complete, First Edition

Very interesting SC - nice one!

[Spacecadet]

I find the Goto method a great lifesaver. Use it all over the place.

Good reading about GOTO statements

Code Complete, First Edition

[hyperD]

I find the Goto method a great lifesaver. Use it all over the place.

[VectraMan]

This is why proper programming languages have const.

[minestrone]

People still want to create anemic domain models for some reason, domain logic gets littered all over the code base in random places. That goes had in hand with...

iAmGoingToTakeThisObjectsAndDoFiftyChangesToIt( aboutToBeAbusedUpTheArseObject ) ;

which is usually written as...

setState( user ) ;

[Ketchup]

And don't forget to make them all static. That'll help out too.

Great suggestion....You should be a lecturer.

From my experience, education in programming teaches how to write code to solve a problem, it doesn't teach how to structure it, standards and best practices. When I was a perm, i hired a number of graduates, they all completed whatever programming tasks i set them, but the code was atrocious.

I think it should be mandatory for any programming degree to teach design patterns, the standards and naming conventions for the languages they are teaching and testing, programmers i deal with in all my contracts do not have a clue about testing even thought most claim they "in-depth" experience of TDD.

Rant over

[RasputinDude]

Just stick to primitive types and you don't have this problem

And don't forget to make them all static. That'll help out too.

[Ketchup]

Just make everything global; then you can do away with silly little things like parameters.

Just stick to primitive types and you don't have this problem

[RasputinDude]

Just make everything global; then you can do away with silly little things like parameters.