Click to See Complete Forum and Search --> : Public Member data, is it really Evil ?


thomus07
October 25th, 2008, 12:47 AM
Dear brother,

Hope you all are well :)


I have been working in C++ and C#. It is a known fact that, member data should not be public or protected inside a class, since it's against OOP.
Now a days, I happen to see in many projects having member data as public. Even big projects designed by arguably experts have this.

Recently I have seen a code in C#, having a class with no member functions at all but all member data public. They have implemented this something like structures in C. I argued them to use properties available in C#, but they said, public data inside a class module is really not that evil, but only lazy to implement it.

I happen to see this more in C# than C++.

As for me, not an expert in C++.
What I follow is, I will use methods with respect to C++ and properties with C#.

Will this kind of design really has potential flaw ?
:)

TheCPUWizard
October 25th, 2008, 01:03 AM
Publically exposing Data imposes limitations against future use.

If you are all powerful and all knowing about how the code will be used by everyone in the future, then there is no problem. Of course if you have this abnility, you also know the winning lottery numbers, have gotten incredibly wealthy and are no longer writing code.

This is even MORE important in .NET because of reflection. If you currently implement something as a field, and then later change it to a property, you will (potentially) break many things that can only be detected at runtime [want to distribute a million copies of your software and then realize your mistake???]

Data should be PRIVATE!

thomus07
October 25th, 2008, 02:51 AM
Publically exposing Data imposes limitations against future use.

If you are all powerful and all knowing about how the code will be used by everyone in the future, then there is no problem. Of course if you have this abnility, you also know the winning lottery numbers, have gotten incredibly wealthy and are no longer writing code.

This is even MORE important in .NET because of reflection. If you currently implement something as a field, and then later change it to a property, you will (potentially) break many things that can only be detected at runtime [want to distribute a million copies of your software and then realize your mistake???]

Data should be PRIVATE!
Thanks TheCpuWizard.

As you said, I would always stick into PRIVATE data in future, no matter what some body follows.
These are valuable suggestions :)