We Keep Coding

Interface reference that specifies I need an object implementing 2 or more interfaces

Let us say I have this overly simple code here:
class Person
{
public int age;
public string name;
public Person(int age, string name)
{
this.age = age;
this.name = name;
}
}
public class MySimpleDatabase
{
List<Person> people;
internal List<Person> People
{
get
{
if(people == null)
{
people = new List<Person>();
people.Add(new Person(24, "ASD"));
people.Add(new Person(35, "QWE"));
people.Add(new Person(12, "MNB"));
}
return people;
}
}
}
public class ProcessPeopleConcrete
{
public void WriteNames()
{
List<Person> people = new MySimpleDatabase().People;
foreach (var person in people)
{
Console.WriteLine(person.name);
}
}
}
public class ProcessPeopleInterface
{
public void WriteNames()
{
//question for here.
IEnumerable<Person> people = new MySimpleDatabase().People;
foreach (var person in people)
{
Console.WriteLine(person.name);
}
}
}
Here I have the concrete processor as well as the interface based one. Here the interface processor is more maintainable of course, but as far as I know
//edited here to clarify
I can specify only one type for a variable that I require, in my case it is the IEnumerable<Person>.
What if I need something there that implements not one, but two interfaces at the same time, that have nothing to do with each other (one doesn't implement the other)?
So say I need any collection that has to implement both ICloneable and IEnumerator. In a comment it was put correctly that I could define another interface that implements both of them. But if I use pre-defined collections, I can't do that becuase then I won't be able to toss any of them as they obviously don't implement my custom made interface.
What sort of type would I specify in this case to my variable people (commented with "question here")? If there was a variable declaration like <IEnumerable, ICloneable> people; that would imaginarily mean I need something that implements both IEnumerable and ICloneable. But is there a language feature similar to that or it is what I said it is - imaginary only?

As you have figured out, you cannot force classes to implement interfaces which they don't ;)
You have also noted that interfaces are used to solve a specific problem. In one case they solve how collections can be enumerated, and in the other case they solve how an object can be cloned.
From your question I take it that you want to be able to tell that the returned object solves both problems and you wonder how you can tell that in the method contract.
You do it by defining a new interface:
public interface ISuperClonableList<T> : IEnumerable<T>, IClonable
{
}
That's it.
If the list itself isn't clonable you need to wrap it in a new class which implements both interfaces. Pass the actual list as a constructor parameter and call it in every IEnumerable method implementation.
The problem with cloning interfaces is that they typically do not specify if it should be a deep or shallow clone. It's important to know that since it can cause large problems if the contained items are mutable.
Example generated from ReSharper:
public class MyListWrapper<T> : ISuperClonableList<T>
{
private readonly ISuperClonableList<T> _innerList;
public MyListWrapper(ISuperClonableList<T> innerList)
{
_innerList = innerList;
}
public IEnumerator<T> GetEnumerator()
{
return _innerList.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return ((IEnumerable) _innerList).GetEnumerator();
}
public void Add(T item)
{
_innerList.Add(item);
}
public void Clear()
{
_innerList.Clear();
}
public bool Contains(T item)
{
return _innerList.Contains(item);
}
public void CopyTo(T[] array, int arrayIndex)
{
_innerList.CopyTo(array, arrayIndex);
}
public bool Remove(T item)
{
return _innerList.Remove(item);
}
public int Count
{
get { return _innerList.Count; }
}
public bool IsReadOnly
{
get { return _innerList.IsReadOnly; }
}
public int IndexOf(T item)
{
return _innerList.IndexOf(item);
}
public void Insert(int index, T item)
{
_innerList.Insert(index, item);
}
public void RemoveAt(int index)
{
_innerList.RemoveAt(index);
}
public T this[int index]
{
get { return _innerList[index]; }
set { _innerList[index] = value; }
}
}

This might not exactly be what you are looking for, but here's something similar to you concept. I created a simple function accepting a Tuple of IEnumerable and IList, then you can feed arguments to it:
public static void Foo(Tuple<IEnumerable<int>, IList<int>> complex)
{
foreach (var item in complex.Item1)
{
Console.WriteLine(item.ToString());
}
complex.Item2.Add(9);
}
A simple list:
List<int> ints = new List<int>
{
1,
3,
5,
7
};
The function is then invoked by either first instantiating a separate variable, as I did, or writing the instantiation right into the Foo() function.
Tuple<IEnumerable<int>, IList<int>> tuple = Tuple.Create((ints as IEnumerable<int>), (ints as IList<int>));
Foo(tuple);
I'm also interested in a real solution though, provided that there is one.

How can I get a unique id for a List<T>

I have a List<T>, where T is a class that has an int field for an id. How is the best way to get a unique id value that has not been used in any of the objects in the List<T>?
How is this procedure normally coded? Is there a data type that can help with this or do I need to store the largest id value?
EDIT
How about when I get an id for an object that is 1. I then delete the object from the List. When I create a new object, I would like the unique id to be 2. In this situation, is there any better way than to store the last unique id?
Thanks.

For that approach I'd write an inherited class of List<T> which holds the logic, so you wouldn't need to implement it everywhere you access the list.
You can even leave it generic if you have a minimum interface which has the Id value.
interface IWithId {
int Id { get; set; }
}
class CustomList<T> : List<T> where T : class, IWithId {
private lastUsedId = 1;
public void AddObjectWithAutomaticId(T newObject) {
newObject.Id = lastUsedId++;
base.Add(newObject);
}
public T GetElementById(int id) {
return base.SingleOrDefault(p => p.Id == id);
}
}
The Remove method would still work as before. The class stores the last used Id, independent what you remove. The Add method is also still available, when you want to add an object with a given Id and not auto-fill it.

I agree with the comment that a GUID would suit you as an id property. If, however, you need to use an int then I suggest a new class.
The problem with inheriting List<T> is that you would have to override multiple methods to ensure that things such as Add(), AddRange(), Insert() can't add duplicate ids and update the stored maximum id. It would be easy to miss one.
I would use a class which doesn't inherit anything, but uses a dictionary internally. This won't have all the same methods as a List<T>, but that's not necessarily a bad thing - it saves mistakes being made and you can have a ToList() method for when they want to query it as if it was a List<T>.
Using part of a previous answer to ensure that T has an Id property gives:
interface IHasId {
int Id { get; set; }
}
class AutoIdList<T> where T : class, IHasId {
private readonly IDictionary<int, T> _dictionary = new Dictionary<int, T>();
//Using this list ensures you don't duplicate ids even
//for an item added with an explicit id then removed
private IList<int> _historicalIds = new List<int>();
private int highestAutoGeneratedId = 0;
public List<T> ToList() {
return _dictionary.Values.ToList();
}
public void Add(T item, bool generateId) {
if (generateId) {
highestAutoGeneratedId = NextId();
T.Id = highestAutoGeneratedId;
}
Add(T);
}
public void Replace(T item) {
_dictionary[item.Id] = item;
}
public void Remove(T item) {
_dictionary.Remove(item.Id);
}
private void Add(T item) {
if (_historicalIds.Contains(T.Id)) {
//throw an appropriate exception
} else {
_historicalIds.Add(T.Id);
_dictionary.Add(T.Id, T);
}
}
private int NextId() {
var id = highestAutoGeneratedId + 1;
while (_historicalIds.Contains(id)) {
id++;
}
return id;
}
//More methods to simulate AddRange, Insert, etc if required. Leave if not.
//Should all have simple logic but require checking of Id if adding anything
//Also need logic to maintain the list of used ids
}

Design pattern for filtering/counting a collection in various states/steps

I'm starting with an IEnumerable and want to run it through several methods that contain LINQ-to-SQL queries, which will filter the result set. Some methods will operate on the original result set, others will operate on a further-filtered result set. However, I want to retain a count of the Excepts (anti-intersections?) of the supplied IEnumerable A and the filtered IEnumerable B so the counts can be sent in an email at the end of all filtering methods. For instance, if Method A is provided a collection of 60 records, but after filtering, the result is down to 20 records, I want to store the number 40 somewhere.
What is the recommended way of keeping track of the counts and collections/queries? I was thinking of using IQueryable and doing Count() within the methods with an out parameter to track the counts, but that just seems messy. Is there some sort of design pattern that fits this process?

interface IFilter<T>
{
IQueryable<T> Filter(IQueryAble<T> data);
}
interface IResultSet<T>
{
int OrignalCount { get; }
int FilteredCount { get; }
IEnumerable<T> Result { get; }
void AddFilter(IFilter<T> filter);
}
and the implementation of IResultSet:
class ResultSet<T> : IResultSet<T>
{
private IQueryable<T> data;
private List<IFilter> filters = new List<IFilter>();
public int OriginalCount {get; private set;}
public int FilteredCount
{
get { return Result.Count(); }
}
public IEnumerable<T> Result
{
get
{
IQueryable data = this.data;
foreach(IFilter filter in filters)
{
data = filter.Filter(data);
}
return data;
}
}
//constructor
public ResultSet<T>(IQueryable<T> data)
{
this.data = data;
this.OriginalCount = data.Count();
}
public void AddFilter(IFilter<T> filter)
{
this.filters.Add(filter);
}
}

Using LINQ with wrapped arrays

I'm new to LINQ and I'm doing a simple project to learn the features of the technology.
Currently I've got a static class that wraps an array of object (a kind of simple factory). Let's say it looks like the following:
public static class Factory
{
private static Item[] items = new Item[]
{
// items are created here
};
// ...
}
Now I can add some functions to my Factory that allow me to query the inner array, e.g.
public static Item GetByID(ItemID id)
{
var query =
from item in items
where item.ID == id
select item;
return query.First();
}
However, this requires me to modify the internals of the Factory class. Is there a way to write such queries from the 'outer world' instead ?
public class OtherClass
{
var result = from it in Factory select ...
}
?

Yes, you can. Just use linq on the Factory from the 'outer world':
public class OtherClass
{
public Item Get(ItemId id)
{
return Factory.Items.SingleOrDefault(i => i.ID == id);
}
}
Of course, to do this, you'd need to change the access modifier of the items array to be public.

There are so many options.
The easiest thing to do is just to expose a public property that allows just what you want to have allowed:
public static class Factory
{
private static Item[] items = new Item[]
{
// items are created here
};
public static IEnumerable<IReadableItem> Items{ get { return items; } }
// ...
}
The above code assumes that the Item class implements an IReadableItem interface that only has the methods and properties on it that you want to allow people to access. You could also clone the items list before returning it each time, if you're worried someone might re-cast the Items or try to modify it using reflection. Because the standard LINQ methods all work off of IEnumerable<>s, this would allow someone to effectively produce a LINQ query on your items, without exposing overmuch data.
List<string> bestItemNames = Factory.Items.Where(i => i.IsBest)
.Select(i => i.Name)
.ToList();
If you wanted to get really fancy, you could even implement your own LINQ provider. From a language perspective, LINQ expression syntax just maps to specific method names, so if you had a class that implemented a .Where() and a .Select() method, then you could implement that pretty much however you wanted, and people wouldn't know any different until they tried doing something that your methods didn't support.

One possibility is to implement IQueryable<T> for a non-static class:
public class Factory<T> : IQueryable<T>
{
protected T[] _items = new T[]{};
public Type ElementType
{
// or typeof(T)
get { return _items.AsQueryable().ElementType; }
}
public System.Linq.Expressions.Expression Expression
{
get { return _items.AsQueryable().Expression; }
}
public IQueryProvider Provider
{
get { return _items.AsQueryable().Provider; }
}
public IEnumerator<T> GetEnumerator()
{
return ( IEnumerator<T> )_items.GetEnumerator();
}
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
return _items.GetEnumerator();
}
}
Derive non-generic class to populate array (if desired)
public class ItemFactory : Factory<Item>
{
public ItemFactory()
{
// items are created here
}
}
Create static instance
public static class Factories
{
private static ItemFactory _itemFactory = new ItemFactory();
public static ItemFactory ItemFactory { get { return _itemFactory; } }
}
Usage:
var specificItem = Factories.ItemFactory
.Where( item => item.ID == id )
.SingleOrDefault();

use an expression tree
public class OtherClass
{
public Item Get(ItemId id)
{
return Factory.Get(i => i.id == id);
}
}
and change the get method to
public Item Get(Expression<Func<Item,bool>> filter)
{
return items.SingleOrDefault(filter);
}
however, this approach makes little sense unless you are encapsulating some other logic in your factory class i.e. select only rows that are not soft deleted.

How can I extend IEnumerable<T> to load my collection from a web service?

I've been trying to puzzle out how I could implement Enumerable<T>/IEnumerator<T> to satisfy the following:
I call a web service to create a query
I poll the web service to find out when it is ready to return results
Once the web service is ready to return results, I call a method (e.g. GetNext(n)) to get n items from it
Once GetNext(n) returns less than n results I have retrieved all of my items.
I'm having some difficulty trying to figure out how I could make an IEnumerable handle all of the heavy lifting from me and the MSDN IEnumerable documentation has not helped.
Here is a simplified version of my code:
public class MyEnumerable : IEnumerable
{
private MyWebService _service;
private int _queryID;
public MyEnumerable(MyWebService service, int queryID)
{
_service = service;
_queryID = queryID;
}
IEnumerator IEnumerable.GetEnumerator()
{
return new MyEnumerator(_service, _query);
}
}
public class MyEnumerator : IEnumerator
{
private List<QueryResult> _items; //want to load my items from WebService into this
private MyWebService _service;
private int _queryID;
private int _index = 0;
private MyEnumerator(MyWebService service, int queryID)
{
_service = service;
_queryID = queryID;
}
public object Current
{
//what goes here?
}
public bool MoveNext()
{
//what goes here? would I call the web service here?
}
public void Reset()
{
_index = 0;
}
}
Hopefully this makes a bit more sense. Let's assume I can call a method on my webservice called GetNext(n).

Rather than explicitly implementing the interface, unless you have a reason not to, you should generally use an iterator block to create such sequences. It will take care of the boilerplate code, just leaving you with the interesting implementation. A problem like this will generally look something along these lines:
//you can make this private if you want
public static IEnumerable<IList<Foo>> GetPages(int pageSize)
{
IList<Foo> nextGroup = ExecuteQuery();
while (nextGroup.Count == pageSize)
{
yield return nextGroup;
nextGroup = ExecuteQuery();
}
if (nextGroup.Any())
yield return nextGroup;
}
You can then use SelectMany to flatten out the list of groups into a list of the individual items:
public static IEnumerable<Foo> GetItems(int pageSize)
{
return GetPages(pageSize).SelectMany(x => x);
}

Use Rx Reactive Extensions, and the Buffer extension method. (Meaning, IObservable rather than IEnumberable). Seems to match your use case perfectly!