Best Practise: Returning private List<> as a Property

[Paul]

Hi,

I feel I'm going around circles on this one and would appreciate some other
points of view.

From a design / encapsulation point of view, what's the best practise for
returning a private List<as a property.

Consider the example below, the class "ListTest" contains a private "List<>"
called "strings" - it also provides a public method to add to that list,
this method could contain all sorts of validation / modification of the
string to be added (encapsulation) . However by then exposing the private
List<as a public property you give the end user of your class the ability
to add to your List<as show below.

I understand why the above happens, I'm just trying to think what the best
course of action is if you always want your user to use the function to add
to your list, whilst retaining a property to access the list? List<>
doesn't contain a clone method - you could create this I know, but then the
amount of processing that involves implies it should be a method rather than
a parameter (parameters shouldn't really consider processor intensive code).

Like I say, I feel I'm going around in circles on this one, even to the
point of wondering if it actually matters.

Regards,

- Paul.
=============== =============== ======
using System;
using System.Collecti ons.Generic;
using System.Text;

class Program
{
static void Main(string[] args)
{
ListTest listTest = new ListTest();
listTest.AddStr ing("Test 1"); // << Add the string the correct way.
Console.WriteLi ne(listTest.Str ings.Count);
listTest.String s.Add("Test 2"); // << by-pass the AddString()
function.
Console.WriteLi ne(listTest.Str ings.Count);
}
}

class ListTest
{
private List<stringstri ngs = null;

public void AddString(strin g stringToAdd)
{
if (strings == null)
strings = new List<string>();
strings.Add(str ingToAdd);
}
public List<stringStri ngs { get { return this.strings; } }
}
=============== =============== ======
Output is:
1
2

[Giulio Petrucci]

Hi Paul,

Paul ha scritto:
[cut]

I think I haven't properly got what you need...
Antyway - taking a look to your code - the best way should be you to
create your *own* collection (implementing ICollection<T>) and
customizing the "Add" method.

HTH,
Giulio

[Dustin Campbell]

I feel I'm going around circles on this one and would appreciate some

other points of view.

From a design / encapsulation point of view, what's the best practise
for returning a private List<as a property.

Consider the example below, the class "ListTest" contains a private
"List<>" called "strings" - it also provides a public method to add to
that list, this method could contain all sorts of validation /
modification of the string to be added (encapsulation) . However by
then exposing the private List<as a public property you give the end
user of your class the ability to add to your List<as show below.

I understand why the above happens, I'm just trying to think what the
best course of action is if you always want your user to use the
function to add to your list, whilst retaining a property to access
the list? List<doesn't contain a clone method - you could create
this I know, but then the amount of processing that involves implies
it should be a method rather than a parameter (parameters shouldn't
really consider processor intensive code).

Like I say, I feel I'm going around in circles on this one, even to
the point of wondering if it actually matters.

=============== =============== ======
using System;
using System.Collecti ons.Generic;
using System.Text;
class Program
{
static void Main(string[] args)
{
ListTest listTest = new ListTest();
listTest.AddStr ing("Test 1"); // << Add the string the correct
way.
Console.WriteLi ne(listTest.Str ings.Count);
listTest.String s.Add("Test 2"); // << by-pass the AddString()
function.
Console.WriteLi ne(listTest.Str ings.Count);
}
}
class ListTest
{
private List<stringstri ngs = null;
public void AddString(strin g stringToAdd)
{
if (strings == null)
strings = new List<string>();
strings.Add(str ingToAdd);
}
public List<stringStri ngs { get { return this.strings; } }
}
=============== =============== ======
Output is:
1
2

List<should be used internally and never exposed. Once you expose it, you're
design is locked into using it. If you just need a way to iterate over the
List<from outside, you might consider making ListTest implement IEnumerable<str ing>
like this:

class ListTest: IEnumerable<str ing>
{
List<stringstri ngs = new List<string>();

public IEnumerator<str ingGetEnumerato r()
{
return strings.GetEnum erator();
}
}

Or, if you want to return the contents, you could expose a read-only indexer:

class ListTest
{
List<stringstri ngs = new List<string>();

public string this[int index] { get { return strings[index]; } }
}

Another option is to return a ReadOnlyCollect ion<string>:

class ListTest
{
List<stringstri ngs = new List<string>();

public ReadOnlyCollect ion<stringStrin gs { get { return strings.AsReadO nly();
} }
}

You might even consider doing all three. But, directly exposing the inner
bits of your class is a bad idea for lots of reasons.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Giulio Petrucci]

Dustin Campbell ha scritto:

List<should be used internally and never exposed. Once you expose it,
you're design is locked into using it. If you just need a way to iterate
over the List<from outside, you might consider making ListTest
implement IEnumerable<str inglike this:

....and if you need to "manipulate " object from outside
(add/remove/clear) you should use a ICollection<T>.

My 2 cents,
Giulio - Italia

--
OnAir: Metallica - the frayed ends of sanity

[Christof Nordiek]

Hi,

you could use the AsReadOnly method of the List<Tclass. It returns a
writeprotected wrapper around your list.

your Strings property would look like this:

public ReadOnlyCollect ion<stringStrin gs { get { return
strings.AsReadO nly() } }

The returned List will still have the Add method soice it implements IList<>
and List<>, but they will cause exceptions.
Not very nice, but atleast the caller can't change your internals.

Christof

"Paul" <no****@noone.c omschrieb im Newsbeitrag
news:OA******** ******@TK2MSFTN GP03.phx.gbl...

Hi,

I feel I'm going around circles on this one and would appreciate some
other points of view.

From a design / encapsulation point of view, what's the best practise for
returning a private List<as a property.

Consider the example below, the class "ListTest" contains a private
"List<>" called "strings" - it also provides a public method to add to
that list, this method could contain all sorts of validation /
modification of the string to be added (encapsulation) . However by then
exposing the private List<as a public property you give the end user of
your class the ability to add to your List<as show below.

I understand why the above happens, I'm just trying to think what the best
course of action is if you always want your user to use the function to
add to your list, whilst retaining a property to access the list? List<>
doesn't contain a clone method - you could create this I know, but then
the amount of processing that involves implies it should be a method
rather than a parameter (parameters shouldn't really consider processor
intensive code).

Like I say, I feel I'm going around in circles on this one, even to the
point of wondering if it actually matters.

Regards,

- Paul.
=============== =============== ======
using System;
using System.Collecti ons.Generic;
using System.Text;

class Program
{
static void Main(string[] args)
{
ListTest listTest = new ListTest();
listTest.AddStr ing("Test 1"); // << Add the string the correct way.
Console.WriteLi ne(listTest.Str ings.Count);
listTest.String s.Add("Test 2"); // << by-pass the AddString()
function.
Console.WriteLi ne(listTest.Str ings.Count);
}
}

class ListTest
{
private List<stringstri ngs = null;

public void AddString(strin g stringToAdd)
{
if (strings == null)
strings = new List<string>();
strings.Add(str ingToAdd);
}
public List<stringStri ngs { get { return this.strings; } }
}
=============== =============== ======
Output is:
1
2

[JS]

...and if you need to "manipulate " object from outside

(add/remove/clear) you should use a ICollection<T>.

I'm just curious. Why is returning an ICollection<Tpr eferrable to
returning an IList<T?

[Bruce Wood]

Paul wrote:

Hi,

I feel I'm going around circles on this one and would appreciate some other
points of view.

From a design / encapsulation point of view, what's the best practise for
returning a private List<as a property.

Consider the example below, the class "ListTest" contains a private "List<>"
called "strings" - it also provides a public method to add to that list,
this method could contain all sorts of validation / modification of the
string to be added (encapsulation) . However by then exposing the private
List<as a public property you give the end user of your class the ability
to add to your List<as show below.

I understand why the above happens, I'm just trying to think what the best
course of action is if you always want your user to use the function to add
to your list, whilst retaining a property to access the list? List<>
doesn't contain a clone method - you could create this I know, but then the
amount of processing that involves implies it should be a method rather than
a parameter (parameters shouldn't really consider processor intensive code).

Like I say, I feel I'm going around in circles on this one, even to the
point of wondering if it actually matters.

Regards,

- Paul.
=============== =============== ======
using System;
using System.Collecti ons.Generic;
using System.Text;

class Program
{
static void Main(string[] args)
{
ListTest listTest = new ListTest();
listTest.AddStr ing("Test 1"); // << Add the string the correct way.
Console.WriteLi ne(listTest.Str ings.Count);
listTest.String s.Add("Test 2"); // << by-pass the AddString()
function.
Console.WriteLi ne(listTest.Str ings.Count);
}
}

class ListTest
{
private List<stringstri ngs = null;

public void AddString(strin g stringToAdd)
{
if (strings == null)
strings = new List<string>();
strings.Add(str ingToAdd);
}
public List<stringStri ngs { get { return this.strings; } }
}
=============== =============== ======
Output is:
1
2

You might choose to use a custom list type. Take a look at how
ListViewItemCol lection works.

[Giulio Petrucci]

Hi JS,

JS ha scritto:

I'm just curious. Why is returning an ICollection<Tpr eferrable to
returning an IList<T?

It's just a more "restricted " interface.

Kind regards,
Giulio

[Paul Hadfield]

Christof,

Thanks for the advice, it's a very clean solution - nice to know that I
wasn't going mad thinking there was a better way of doing things.

Also, you have to cast the returned "ReadOnlyCollec tion" property as a
"ICollection<T> " to get the Add value because it's an Explicit Interface
implementation (see below) - if you just use the property without the cast
you can't even see / use the Add method.

((ICollection<S tring>)listTest .Strings).Add(" Test 2"); // << This will throw
the exception.

Thanks again,

- Paul.

"Christof Nordiek" <[e-mail] ote in message
news:uR******** ******@TK2MSFTN GP02.phx.gbl...

Hi,

you could use the AsReadOnly method of the List<Tclass. It returns a
writeprotected wrapper around your list.

your Strings property would look like this:

public ReadOnlyCollect ion<stringStrin gs { get { return
strings.AsReadO nly() } }

The returned List will still have the Add method soice it implements
IList<and List<>, but they will cause exceptions.
Not very nice, but atleast the caller can't change your internals.

Christof

"Paul" <no****@noone.c omschrieb im Newsbeitrag
news:OA******** ******@TK2MSFTN GP03.phx.gbl...

>Hi,

I feel I'm going around circles on this one and would appreciate some
other points of view.

From a design / encapsulation point of view, what's the best practise for
returning a private List<as a property.

Consider the example below, the class "ListTest" contains a private
"List<>" called "strings" - it also provides a public method to add to
that list, this method could contain all sorts of validation /
modification of the string to be added (encapsulation) . However by then
exposing the private List<as a public property you give the end user of
your class the ability to add to your List<as show below.

I understand why the above happens, I'm just trying to think what the
best course of action is if you always want your user to use the function
to add to your list, whilst retaining a property to access the list?
List<doesn't contain a clone method - you could create this I know, but
then the amount of processing that involves implies it should be a method
rather than a parameter (parameters shouldn't really consider processor
intensive code).

Like I say, I feel I'm going around in circles on this one, even to the
point of wondering if it actually matters.

Regards,

- Paul.
============== =============== =======
using System;
using System.Collecti ons.Generic;
using System.Text;

class Program
{
static void Main(string[] args)
{
ListTest listTest = new ListTest();
listTest.AddStr ing("Test 1"); // << Add the string the correct
way.
Console.WriteLi ne(listTest.Str ings.Count);
listTest.String s.Add("Test 2"); // << by-pass the AddString()
function.
Console.WriteLi ne(listTest.Str ings.Count);
}
}

class ListTest
{
private List<stringstri ngs = null;

public void AddString(strin g stringToAdd)
{
if (strings == null)
strings = new List<string>();
strings.Add(str ingToAdd);
}
public List<stringStri ngs { get { return this.strings; } }
}
============== =============== =======
Output is:
1
2

[Paul Hadfield]

Thanks Dustin,

That's really helpful - I've gone with the ReadOnlyCollect ion option as it
does exactly what I wanted - sometimes I do want to return the whole
collection, not just iterate over it or return specific elements.

Regards,

- Paul.
"Dustin Campbell" <du*****@no-spam-pleasedevexpres s.comwrote in message
news:c1******** *************** ***@news.micros oft.com...

>I feel I'm going around circles on this one and would appreciate some
other points of view.

From a design / encapsulation point of view, what's the best practise
for returning a private List<as a property.

Consider the example below, the class "ListTest" contains a private
"List<>" called "strings" - it also provides a public method to add to
that list, this method could contain all sorts of validation /
modification of the string to be added (encapsulation) . However by
then exposing the private List<as a public property you give the end
user of your class the ability to add to your List<as show below.

I understand why the above happens, I'm just trying to think what the
best course of action is if you always want your user to use the
function to add to your list, whilst retaining a property to access
the list? List<doesn't contain a clone method - you could create
this I know, but then the amount of processing that involves implies
it should be a method rather than a parameter (parameters shouldn't
really consider processor intensive code).

Like I say, I feel I'm going around in circles on this one, even to
the point of wondering if it actually matters.

============== =============== =======
using System;
using System.Collecti ons.Generic;
using System.Text;
class Program
{
static void Main(string[] args)
{
ListTest listTest = new ListTest();
listTest.AddSt ring("Test 1"); // << Add the string the correct
way.
Console.WriteL ine(listTest.St rings.Count);
listTest.Strin gs.Add("Test 2"); // << by-pass the AddString()
function.
Console.WriteL ine(listTest.St rings.Count);
}
}
class ListTest
{
private List<stringstri ngs = null;
public void AddString(strin g stringToAdd)
{
if (strings == null)
strings = new List<string>();
strings.Add(st ringToAdd);
}
public List<stringStri ngs { get { return this.strings; } }
}
============== =============== =======
Output is:
1
2

List<should be used internally and never exposed. Once you expose it,
you're design is locked into using it. If you just need a way to iterate
over the List<from outside, you might consider making ListTest implement
IEnumerable<str inglike this:

class ListTest: IEnumerable<str ing>
{
List<stringstri ngs = new List<string>();

public IEnumerator<str ingGetEnumerato r()
{
return strings.GetEnum erator();
}
}

Or, if you want to return the contents, you could expose a read-only
indexer:

class ListTest
{
List<stringstri ngs = new List<string>();

public string this[int index] { get { return strings[index]; } }
}

Another option is to return a ReadOnlyCollect ion<string>:

class ListTest
{
List<stringstri ngs = new List<string>();

public ReadOnlyCollect ion<stringStrin gs { get { return
strings.AsReadO nly(); } }
}

You might even consider doing all three. But, directly exposing the inner
bits of your class is a bad idea for lots of reasons.

Best Regards,
Dustin Campbell
Developer Express Inc.