We Keep Coding

Using an Interface as a Parameter Type For Method, Can this work?

my question is, if you have a method of the form:
public bool ProcessAggregation(IAggregatePoint point) { #do stuff }
And a class, NetworkAggregation, implementing IAggregatePoint. Can you call the method like:
ProcessAggregation(point) where point here is a NetworkAggregation instance?
Also, if not possible with interfaces, could inheritance of an abstract base class work? Meaning any object inheriting from the abstract base class would be passible into the method?
I am reluctant to alter the classes with inheritance as they are database schemas for a MySql database/ used with EntityFramework.
Thanks!
Network aggregation is implemented like:
public class NetworkAggregation : IAggregatePoint
{
public DateTime? AssessmentDate {get; set;}
public int Id {get; set;}
public string DUPValue {get; set;}
//And so on, other properties not specified in IAggregatePoint
}
and IAggregatePoint is implemented like:
public interface IAggregatePoint
{
public DateTime? AssessmentDate {get; set;}
}

Yes, this will work. As long as a class implements the IAggregatePoint interface, an instance of that class can be provided to ProcessAggregation without any issues. You'll get a compiler error if you make a mistake (like trying to use a method that is from NetworkAggregation but not part of IAggregatePoint within ProcessAggregation).
You could also do the same thing with an abstract base class, as you mentioned.
It might be worthwhile to review the C# language specification's documentation on interfaces.
Edit - here's a simple, working example:
public interface IAggregatePoint
{
}
public class NetworkAggregation : IAggregatePoint
{
}
public class AnotherAggregation
{
}
public void Test()
{
// works because NetworkAggregation implements IAggregatePoint
ProcessAggregation(new NetworkAggregation());
// fails to compile (as expected) because AnotherAggregation
// doesn't implement IAggregatePoint
ProcessAggregation(new AnotherAggregation());
}

How to get base class object from closed constructed class in C#

Just another small C# training app, and just another Compilation Error, but it cannot just go away from me... I am just wondering, what I am doing wrong here:
public abstract class Material
{
}
public abstract class Cloth<T> where T:Material
{
public T Prop { get; set; }
}
public class Cotton : Material
{
}
public class Dress<T> : Cloth<T> where T : Material
{
}
public class Test
{
private Cloth<Material> cloth;
public Test()
{
/* below won't compile */
cloth = new Dress<Cotton>();
}
}
I want to get the base class object from a closed constructed class. Anyone ?
When trying to compile I get the error:
Cannot implicitly convert type Dress<Cotton> to Cloth<Material>

What you want to achieve is called covariance (see the following article for samples).
Unfortunately, there's no variance support for classes: it's restricted to interfaces and delegates.
Thus and alternatively, you might design an interface called ICloth<T> with T covariant:
public interface ICloth<out T>
{
T Prop { get; set; }
}
And implement it in any of your possible cloths, including Cloth<T>.
Now type cloth as ICloth<T> and your assignment should work (i.e. cloth = new Dress<Cotton>();), because Dress<Cotton> is ICloth<out T>, which is an interface with a T covariant generic parameter.
Learn more about generic interface with variance in the following article on MSDN.

Why I cannot implement an interface on a class replacing an interface with a concrete type? [duplicate]

This question already has answers here:
The return type of the members on an Interface Implementation must match exactly the interface definition?
(6 answers)
Does C# support return type covariance?
(9 answers)
Closed 8 years ago.
Why can I not do the following?
public class TestClass : TestInterface
{
public ClassX Property { get; private set; }
}
public interface TestInterface
{
InterfaceX Property { get; }
}
public interface InterfaceX
{
}
public class ClassX : InterfaceX
{
}
The TestInterface Property is readonly, thus can only return InterfaceX as per the contract.
However, I get this compiler error:
'TestClass' does not implement interface member
'TestInterface.InterfaceX'. 'TestClass.InterfaceX' cannot implement
'TestInterface.InterfaceX' because it does not have the matching
return type of 'InterfaceX'.
It does not have the matching type but it has a subclass of that type.

I don't know the spec offhand, but I'm sure there's one that explicitly states that return types must match exactly for interface implementations. The closest I can find is 13.4.4:
For purposes of interface mapping, a class member A matches an interface member B when:
A and B are methods, and the name, type, and formal parameter lists of A and B are identical.
A and B are properties, the name and type of A and B are identical, and A has the same accessors as B (A is permitted to have additional accessors if it is not an explicit interface member implementation).
If "type" above means "return type" that would indicate that the return type cannot change.
You could, however, change the return type and explicitly implement the interface with the right return type:
public class TestClass : TestInterface
{
public ClassX InterfaceX { get; private set; }
InterfaceX TestInterface.InterfaceX { get { return InterfaceX; } }
}
UPDATE
According to Eric Lippert it seems to be a CLR limitation, not just a C# one.

You mentioned that you want to expose a reduced set but you want all the functionality internal to the class -- that's not what you want to use an interface for. An interface should only be about your reduced set contract, not also magically function as a full set internally, not without another helper property.
But, there is a way around this limitation while still communicating the contract a little.
interface IExpose<IToolType> where IToolType : ITool
{
IToolType Handler { get; set; }
}
class Expose : IExpose<Tool>
{
public Tool Handler { get; set; }
}
interface ITool
{
}
class Tool : ITool
{
}

Declaring interface on abstract base class

I am currently implementing the Quartz timer to allow scheduling of some data files. I have a abstract DataOutput class and then implementations to cover the different types of output (http, file, etc). I have implemented the interface on both specialisations but I am having compilation errors when I try and declare this on the abstract base in order to create objects of type DataOutput so I can deal with these at runtime.
Is this possible?

You'll need to at least abstractly implement the interface:
public interface IExample
{
string Word { get; set; }
void DoIt();
}
public abstract class ExampleClass : IExample
{
public string Word { get; set; }
public abstract void DoIt();
}
I'm not sure if you've done this since you didn't post any code or errors.

How to force multiple Interfaces to include the same properties?

I am trying to figure out a way to force all of my Interfaces to include properties of the same name/type.
For example: I have two Interfaces; IGetAlarms and IGetDiagnostics. Each of the Interfaces will contain properties that are specific to the Interface itself, however I want to force the two Interfaces (and all other Interfaces that may be added later) to include properties of the same name. So, the result may look something like the this:
interface IGetAlarms
{
string GetAlarms();
DateTime LastRuntime { get; set; }
}
interface IGetDiagnostics
{
string GetDiagnostics();
DateTime LastRuntime { get; set; }
}
Notice that both Interfaces include a DateTime property named LastRuntime.
I would like to know if there is some way I can force other Interfaces that will be added later to include the DateTime LastRuntime property. I have naively attempted to have all my Interfaces implement another Interface (IService) - which includes the LastRuntime property. However, that doesn't solve my problem as that simply forces the class to implement the property - not all the Interfaces.
Thanks.

An interface can inherit from other interfaces.
interface IDerived : IBase
{
string Foo { get; set; }
}
interface IBase
{
DateTime LastRunDate { get; set; }
}
Any class deriving from IDerived will have to implement the methods/properties of IBase as well.
class Derived : IDerived
{
#region IDerived Members
public string Foo { get; set; }
#endregion
#region IBase Members
public DateTime LastRunDate {get;set;}
#endregion
}

If I understand your question correctly, you want to force a class to implement a number of different interfaces, the list of interfaces will grow with time but will have some properties in common.
The common property part you have solved with your IService interface. Something like this, I presume
interface IService
{
DateTime LastRuntime { get; set; }
}
interface IGetAlarms : IService
{
string GetAlarms();
}
interface IGetDiagnostics : IService
{
string GetDiagnostics();
}
The growing list of interfaces that a class will have to implement you can also solve in a similar fashion. Create a "composite" interface which inherits from all the interfaces you wish your class to implement
interface IComposite : IGetAlarms, IGetDiagnostics {}
class MyClass : IComposite
{
...
}
When you let the IComposite interface inherit a new interface, the class will have implement the new interface too.
EDIT
In response to your clarification; in that case you should not share the specification of the LastRuntime property, but declare it in each individual interface. In the implementing class you can use Explicit interface member implementation
class MyClass : IComposite
{
DateTime IGetAlarms.LastRuntime { get; set; }
DateTime IGetDiagnostics.LastRuntime { get; set; }
...
}
However, AFAIK it is not possible to force the implementing class to explicitly implement each individual interface

It really depends on exactly what you need the interface for. You can use generics to enforce the implementation of a specified pattern, but you can't enforce the implementation of each individually if they all have identical signatures.
public interface IA<T> where T: class
{
void DoIt(T ignore = null);
}
public interface IB : IA<IB>
{
}
public interface IC : IA<IC>
{
}
That would force the following class to implement each separately:
public class D : IB, IC
{
public void DoIt(IB ignore = null) { }
public void DoIt(IC ignore = null) { }
}
It's the "T ignore" parameter that forces each one to be implemented separately, and since it has a default value, you can just ignore that parameter unless calling it using reflection.
But obviously this doesn't work with properties, so they would have to be implemented using getter/setter methods.