1

It seems like a trivial task but I can't find how to do it (and don't know what to call it).

Example. I need class state that is in fact just list of strings. It must work so:

state s = new state();
s.Add("John Madden");
//s[0] == "John Madden"

And I need to add to this class some methods.

jpbochi
  • 4,366
  • 3
  • 34
  • 43
InfernumDeus
  • 1,185
  • 1
  • 11
  • 33
  • 4
    You could have `State` implement `IList`. – David Mar 04 '15 at 13:27
  • You can create your own custom collection and enrich it with your custom methods. https://msdn.microsoft.com/en-us/library/xth2y6ft(v=vs.71).aspx – user3021830 Mar 04 '15 at 13:28
  • 1
    Does `state` itself have to represent a list? or can it encapsulate one? – Yuval Itzchakov Mar 04 '15 at 13:29
  • 4
    If your class really is just a `List`, then maybe what you really want to do is go ahead and use a `List` instead of defining your own class. The "custom methods" can simply be extension methods. Unfortunately, your question is fairly vague about what these "custom methods" really are, and why it is you feel you want a dedicated class for the `State` object. – Peter Duniho Mar 04 '15 at 13:29

4 Answers4

6

You can just inherit from it:

public class State : List<string>
{}

That way, you have the full interface that List<string> offers, with your own type name. And then you can go, and add your own methods.

If you want a bit more control over it, e.g. to hide some methods or to change how they work, you could also create a wrapper class that implements IList<string> and just delegates most of its method to a private List<string> instance. E.g. like this:

public class State : IList<string>
{
    private List<string> internalList = new List<string>();

    public string this[int index]
    {
        get { return internalList[index]; }
        set { internalList[index] = value; }
    }

    public void Add (string item)
    {
        internalList.Add(item);
    }

    // etc. for the other IList<T> members
}
poke
  • 369,085
  • 72
  • 557
  • 602
1

I don't know your exact requirements, but maybe it would be a suitable approach to stick with List and use extension methods for your additional functionality.

public static class ListExtensions 
{
    public static void DoSomethingWithMyStrings (this List<string> list)
    {
        // Implement your additional functionality here
    }
}

// Usage:
using ListExtensions;

var myList = new List<string>();
myList.Add("blah");
myList.DoSomethingWithMystrings ();
Thomas F.
  • 717
  • 3
  • 13
  • 1
    I'm actually have pretty messy classes structure and inherited class will make code more clear. But thank you for tip! I can use it in later projects. – InfernumDeus Mar 04 '15 at 14:00
0

Instead of inheriting a list, i would choose to encapsulate one (a great reason for why can be found here).

If you need to have State hold custom, state related methods, they have nothing to do with a List<string> derived class.

public class State
{
    public List<string> FooBar { get; set; }

    public void Foo() { }
    public void Bar() { }
}
Community
  • 1
  • 1
Yuval Itzchakov
  • 146,575
  • 32
  • 257
  • 321
  • I agree that encapsulation is often a better approach but I don't necessarily agree with the sentiment of Eric's answer - in truth, trying to draw direct parallels between classes and their "real life" counterparts and derive technical solutions from those parallels is usually more harmful than useful - this kind of thing should generally be considered on its technical merits rather than its semantics. I'm sure purist DDD proponents would disagree with me but there you go. – Ant P Mar 04 '15 at 13:37
  • @AntP That's alright, we don't have to agree. I simply think having custom methods on an inheretor of `List` which aren't directly related to a `List` would feel weird. – Yuval Itzchakov Mar 04 '15 at 13:43
  • I don't disagree with that - that is simply good encapsulation. I just think that the basis of the other answer you linked to is too focused on deriving technical decisions on domain semantics rather than actual technical merit. – Ant P Mar 04 '15 at 13:44
  • 1
    @InfernumDeus the public contract of your object that inherits from `List` will look much worse (what does using LINQ on my state object accomplish?) and expose way more than you need to. An object that encapsulates the list will have a contract with methods and properties that explain exactly how you are supposed to interact with the object (instead of, say, being able to call `Aggregate()` over your state object). – moarboilerplate Mar 04 '15 at 18:26
0

Try to inherit from Collection<String>, this is a better way then using List: Collection versus List what should you use on your interfaces?

public class State : Collection<string>

List is not designed to be easily extensible by subclassing it; it is designed to be fast for internal implementations. You'll notice the methods on it are not virtual and so cannot be overridden, and there are no hooks into its Add/Insert/Remove operations.

Community
  • 1
  • 1
Leo Chapiro
  • 13,678
  • 8
  • 61
  • 92