C# Discussion Boards - CodeProject

26-Oct-08 22:40

Hi all,

Could someone perhaps give me a little more insight into the workings of the get and set properties?

Let's say I have the following class:

public class MyClass
{
    private byte[] _myArray;

    public byte[] MyArray
    {
        get { return _myArray; }
        set { _myArray = value; }
    }

    public MyClass()
    {
        _myArray = new byte[10];
    }
}

I can now access the member array of the class as follows:
byte[] NewArray = MyInstanceOfClass.MyArray;
and I can set it as follows:
MyInstanceOfClass.MyArray = new byte[] {0,1,2,3,4,5,6,7,8,9};
or
MyInstanceOfClass.MyArray = NewArray;

In all three examples I'm accessing the entire array as a unit. Is it also correct to access only individual elements of the array? Does the get/set properties allow for that or am I supposed to set them up differently?

By writing a little test app it seems to be working but is this the correct way of doing it?

byte MyByte = MyInstanceOfClass.MyArray[5];
and
MyInstanceOfArray.MyArray[5] = 123;

leppie26-Oct-08 22:45

leppie

26-Oct-08 22:45

Yes, the content of an array is mutable.

xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 beta 1 - out now!
((lambda (x) `((lambda (x) ,x) ',x)) '`((lambda (x) ,x) ',x))

Nagy Vilmos27-Oct-08 3:20

Nagy Vilmos

27-Oct-08 3:20

leppie wrote:
the content of an array is mutable

To follow on, you would be better to use methods to access the elements rather then the array:

public byte getItem(int item)
{
    return MyArray[item];
}

public void setItem(int item, byte value)
{
    MyArray[item] = value;
}

Panic, Chaos, Destruction.
My work here is done.

Dewald27-Oct-08 3:41

27-Oct-08 3:41

williamnw wrote:
To follow on, you would be better to use methods to access the elements rather then the array

Why is that? To me it just seems more unwieldy. Here's an example why I think so:

Let's say you I have two instances of the above class and I want to set the value in one instance to be one bigger than the corresponding value in the other instance.

Using the methods as you recommend it would look like this:
MyFirstInstance.setItem(i, MySecondInstance.getItem(i)+1);
whereas, if using the get/set properties, it would look like this:
MyFirstInstance.MyArray[i] = MySecondInstance.MyArray[i]+1;

Both work, but to me the second line is just much more readable. Also, if I use the methods as suggested, I don't have access to MyArray.Length or any of the member methods of System.Array unless I explicitly code them.

What am I missing?

Nagy Vilmos27-Oct-08 4:34

Nagy Vilmos

27-Oct-08 4:34

You're missing that the data is not being hidden.
If you WANT the array to be changed by an eternal class, then expose it, but it's not a great idea.
If you want the elements to be exposed then use a method that hides the implimentation.

Panic, Chaos, Destruction.
My work here is done.

Dewald27-Oct-08 3:30

27-Oct-08 3:30

Aha, so that's what mutability is. I've heard the term and read the quick definition - something like "a mutable class is one of which the contents can change". Duh! That hardly sounds like a useful description. At least now I have a practical example of where it becomes significant. Thanks.

Mark Salsbery27-Oct-08 5:18

Mark Salsbery

27-Oct-08 5:18

Dewald wrote:
now I have a practical example of where it becomes significant.

Objects of the String class are immutable, and used quite often...that's a pretty
significant practical example Smile | :)

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Dewald27-Oct-08 5:38

27-Oct-08 5:38

Cool, now I have two examples, thanks Wink | ;-)

method in interface

George_George26-Oct-08 21:20

26-Oct-08 21:20

Hello everyone,

I understand in the rule of C#, we are not allowed to add public/private/protected qualifier to methods in interface. My question is why adding the qualifiers are not allowed? I want to know the reason behind the claimed rule, i.e. what issues will be if we are allowed to add qualifier?

thanks in advance,
George

Guffa26-Oct-08 22:39

Guffa

26-Oct-08 22:39

There is no purpose of having qualifiers for the members of an interface. If they are not public, they are not useable at all.

A private member doesn't make sense at all. Making a member protected would only force you to implement it, but it would not be reachable for any code that uses the interface.

Despite everything, the person most likely to be fooling you next is yourself.

George_George27-Oct-08 1:42

27-Oct-08 1:42

Thanks Guffa!

1.

I can understand that you mean if interface method is marked as private, then the implementation must be private and the implementation could not be accessed from outside? Is that your point?

2.

My confusion is what do you mean "Making a member protected would only force you to implement it, but it would not be reachable for any code that uses the interface."? Could you show some pseudo code to describe your ideas please?

regards,
George

DaveyM6927-Oct-08 2:53

DaveyM69

27-Oct-08 2:53

Anything that's private in an object can only be accessed by that object itself so it is pointless in an interface as is protected as they can only be accessed by the class itself or ones derived from it.

I thought about this too when I first used interfaces. If all the objects that are going to implement the interface will have a specific private method for example then it makes sense to put the private method in the interface so each object has to implement it... If that were possible, it would save alot of typing (or copying/pasting) sometimes but that's not what interfaces are for!

Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)

George_George27-Oct-08 3:44

27-Oct-08 3:44

Hi Dave!

I disagree with you that in the implementation, we could provide accessor like private, here is my code with compile error when we add private qualifier to implementation method. Any comments?

interface IFoo 
{ 
void Abc(); 
} 

class Foo : IFoo 
{ 
private void IFoo.Abc() 
{ 

} 
} 
D:\Visual Studio 2008\Projects\TestInterface2\TestInterface2\Program.cs(15,22): error CS0106: The modifier 'private' is not valid for this item

regards,
George

DaveyM6927-Oct-08 4:12

DaveyM69

27-Oct-08 4:12

Exactly my point - we can't because it would be pointless.

Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)

George_George30-Oct-08 3:29

strongly named assembly issue

30-Oct-08 3:29

Thanks Dave!

1.

Last confirmation, both methods in interface and methods in implementation class must be private?

2.

interface IFoo
{
    void Abc();
}

class Foo : IFoo
{
    private void Abc() {}

    void IFoo.Abc() { this.Abc(); }
}

If yes to 1, I disagree. I did some investigation, seems when there is both implicit and explicit implementation, we could have a private implementation?

regards,
George

George_George26-Oct-08 20:51