Using internal modifier on set accessor ..

  • Thread starter Thread starter Anders Borum [.NET/C# MCP]
  • Start date Start date
A

Anders Borum [.NET/C# MCP]

Hello!

With C# 2.0 coming up, I was wondering what your thoughts are regarding the
introduction of access modifiers on set accessors.

Personally, I like the first example, because of its simplicity. The second
seems rather dangerous and the third one - well, quite verbose.

I'm trying to communicate best practices to fellow developers in-house - and
figured some of you already had experience from past projects / languages
with such features.

Your thoughts?

// 1 - using C# 2.0 access modifer on member
public class CmsObject
{
private Guid cmsObjectID;

public Guid CmsObjectID
{
get { return this.cmsObjectID; }
internal set { this.cmsObjectID = value; }
}
}

vs.

// 2 - using an internal access modifier on member
public class CmsObject
{
internal Guid cmsObjectID;

public Guid CmsObjectID
{
get { return this.cmsObjectID; }
}
}


vs.

// 3 using a method to set member
public class CmsObject
{
private Guid cmsObjectID;

public Guid CmsObjectID
{
get { return this.cmsObjectID; }
}

internal void SetCmsObjectID(Guid cmsObjectID)
{
this.cmsObjectID = cmsObjectID;
}
}

Thanks in advance.
 
Hi,

the reason for encapsulating a member field into a property in the first
place is usually because set and get are associated with some kind of
behaviour.

Leaving the field accessible directly to bypass encapsulation is
therefor, in my opionion, breaking good OO design and are breaking
encapsulation.

Also if you are using propertys, there's really no need to use separate
set or get methods to write and read from the data. All access to that
particular member should be in a single place.

So I would say that your code snippet 1 is the one that makes the most
sense in a true OO environment.

Additionally I would like to add that if you have a field encapsulated
into a property, you should make it a rule to always access that field
throught a property even inside your class. Why? Well as I said earlier,
you encapsulate a field for a reson.
 
Hello Patrik

First of all, thanks for sharing your thoughts.
the reason for encapsulating a member field into a property in the first
place is usually because set and get are associated with some kind of
behaviour.
Click to expand...

Well, I have never been a fan of exposing member fields directly without
wrapping them in a set of accessors. There are a few cases where I use
private configuration classes etc. that are used with serialization, but I
would never do it with a public exposed interface.
Leaving the field accessible directly to bypass encapsulation is
therefor, in my opionion, breaking good OO design and are breaking
encapsulation.
Click to expand...

I agree.
So I would say that your code snippet 1 is the one that makes the most
sense in a true OO environment.
Click to expand...

Glad to hear that, I was also under the impression that
Additionally I would like to add that if you have a field encapsulated
into a property, you should make it a rule to always access that field
throught a property even inside your class. Why? Well as I said earlier,
you encapsulate a field for a reson.
Click to expand...

Well, some times it can be useful to access the field directly without going
through the public property.

With regards
Anders Borum / SphereWorks
Microsoft Certified Professional (.NET MCP)
 
Back
Top