We Keep Coding

Trying to understand C# nested interfaces

I'm trying to get a simple set of interfaces to be nested so I can enforce some members on derived classes.
public enum Category { Mental, Physical, Technical }
interface IAbilities
{
List<IAbility> Abilities { get; set; }
}
interface IAbility
{
Category Category { get; }
int Value { get; set; }
string Descritpion { get; set; }
}
public class MentalAbilities : IAbilities
{
// This is what I want so that "Abilities" is accessible
public List<MentalAbility> Abilities { get; set; }
// This is what Intellisense generates, cannot be set to public
//List<IAbility> IAbilities.Abilities { get; set; }
}
public class MentalAbility : IAbility
{
public Category Category { get; } category
public int Value { get; set; }
public string Descritpion { get; set; }
}
Of course the Intellisense generated bit compiles, but "Abilities" is not accessible from a class instance because it can't be set to public.
The bit I want tells me `'MentalAbilities' does not implement interface member 'IAbilities.Abilities'. 'MentalAbilities.Abilities' cannot implement 'IAbilities.Abilities' because it does not have the matching return type of List<IAbility>.
I don't understand since "MentalAbility" is derived from the "IAbility" interface so that should fulfill the contract.

(I'm skipping over the "x is less accessible than y" error because you already worked out you can make your interfaces public - sure you can appreciate how anything has to be at least as accessible as it's use)
Re your "does not implement" error:
I understand your problem, but you've kinda got it upside down
I see that you want to ensure, in your MentalAbilities.Abilities list, someone only puts MentalAbility objects.. and they implement IAbility so it should satisfy the "object is a IAbilities and has a list which contains only things that implement IAbility" rules, right?
Alas, no. This the pretty much the opposite of what inheritance or interface implementation is for.
The idea behind inheritance is that you can say "this thing can be any type at all as long as it has these common aspects and I will treat it in the common way". By declaring such that List<IAbility> you're saying "objects in this list just have to implement IAbility and then I'll be able to deal with them" - it could be a MentalAbility, or a PhysicalAbility - doesn't matter
You cannot then constrain the list to only containing MentalAbility via the inheritance/implements mechanism, nor should you because it's opposite of what it is for- going from "I can deal with anything so long as it implements X" to "I will only deal with something if it is, or is a subtype of, Y" is the opposite of what was claimed earlier. You're saying that MentalAbilities can only deal with the list contents if they're MentalAbility, when you earlier said it could deal with anything that was an IAbility
If you want to enforce that MentalAbilities only contains MentalAbility you'll have to declare it as List<IAbility> and look at the type of the IAbility you're given in the set and refuse to add it if if it's not a MentalAbility, but if other developers use your code they will be very confused - "what? It says I'm allowed to use anything that implements IAbility, and my TigerAbility does just that.. why am I getting an exception that it must be a MentalAbility? Why did this developer even use a List(IAbility) if I'm not allowed to sling any IAbility I like into it?" - it's also no longer a compile time thing, but a runtime one and that's a big risk
I think you need to decide if you're going to be able to treat these things in a generic way i.e. can your AbilitiesProcessor implement IAbilities and have a list of IAbility and process them regardless of actual type, or not. If it can't, and you're going to have a MentalAbilities class that can only deal with MentalAbility that's fine, and it can have a List<MentalAbility> all it wants, fellow developers won't mistakenly put a TigerAbility into it, but it won't implement the IAbilities interface

I'm trying to get a simple set of interfaces to be nested so I can enforce some members on derived classes.
Your main issue here is that defined the two interfaces as private by default. That's what is preventing you from creating public List<IAbility> Abilities { get; set; } inside MentalAbilities.
Actually, the property public List<MentalAbility> Abilities { get; set; } is also preventing you as you can't have a property of the same name defined twice.
The big question here would be what would be the point of allowing MentalAbilities the ability to set a List<IAbility> since that would mean setting any type of ability.
Ideally MentalAbilities should only have a single list of MentalAbility that it contains - and it should only be read-only. In fact, most of your interfaces should be read-only.
Here's what you should do:
Start with these interfaces:
public interface IAbilities<A> where A : IAbility
{
List<A> Abilities { get; }
}
public interface IAbility
{
Category Category { get; }
int Value { get; }
string Description { get; }
}
Notice the IAbilities<A> interface uses a generic type A that you can fill in later.
Next, let's set up some base classes that simplify the implementation of each specific class.
public abstract class AbilitiesBase<A> : IAbilities<A> where A : IAbility
{
public List<A> Abilities { get; protected set; }
}
public abstract class AbilityBase : IAbility
{
public abstract Category Category { get; }
public abstract int Value { get; }
public abstract string Description { get; }
}
Now the final classes are simple:
public class MentalAbilities : AbilitiesBase<MentalAbility> { }
public class MentalAbility : AbilityBase
{
public override Category Category => Category.Mental;
public override int Value => 42;
public override string Description => "Mental!";
}
There's nothing to implement in MentalAbilities - the base class took care of that - but it does have a List<MentalAbility> Abilities { get; } property.
MentalAbility is also neatly set up to enforce you to override the properties.
Now, if you actually wanted still have a List<IAbility> Abilities { get; } property then there's an easy way to do that by writing these two interfaces:
public interface IAbilities
{
List<IAbility> Abilities { get; }
}
public interface IAbilities<A> : IAbilities where A : IAbility
{
new List<A> Abilities { get; }
}
This forces a change to AbilitiesBase like this:
public abstract class AbilitiesBase<A> : IAbilities<A> where A : IAbility
{
public List<A> Abilities { get; protected set; }
List<IAbility> IAbilities.Abilities => this.Abilities.Cast<IAbility>().ToList();
}
The List<IAbility> IAbilities.Abilities property generates a copy of the public List<A> Abilities { get; protected set; } property, but that's what you want to prevent anyone adding the wrong type of ability to the original list.
Personally, I would go with this instead:
public interface IAbilities
{
IEnumerable<IAbility> Abilities { get; }
}
public interface IAbilities<A> : IAbilities where A : IAbility
{
new List<A> Abilities { get; }
}
public abstract class AbilitiesBase<A> : IAbilities<A> where A : IAbility
{
public List<A> Abilities { get; protected set; }
IEnumerable<IAbility> IAbilities.Abilities => this.Abilities.Cast<IAbility>();
}

What you are stuck with is called implicit and explicit implementation of interfaces in C#. If you define your class member like this:
public List<MentalAbility> Abilities { get; set; }
you are implementing IAbilities implicitly and you need to write public with it. If you define your class member as
List<IAbility> IAbilities.Abilities { get; set; }
you have implemented IAbilities explicitly, in which case it can be private.
While we are here, I see no point in defining an interface IAbilities. You should simply use IEnumerable<IAbility> anywhere you want to use IAbilities, which is literally providing no value in your code.

No derived ViewModels but the same behavior?

I'm writing a small wpf desktop application. My BaseViewModel looks like this:
public abstract class BaseViewModel : INotifyPropertyChanged, IComparable<BaseViewModel>
{
public abstract string GetDisplayText();
public abstract string GetImageName();
// INotifyPropertyChanged
}
I was looking for a best paxis for mvvm. The most say, that there are multiple ViewModels for one Model and I agree to it.
Because I want that all ViewModels of the same type handle the basics in the same way, i thougth they should derived from each other.
public abstract class BaseCustomerVm : BaseViewModel
{
public abstract string Name { get; set; }
public abstract int Number { get; set; }
public abstract bool IsPerson { get; set; }
public override string GetDisplayText()
{
return Name;
}
public override string GetImageName()
{
if (IsPerson)
return "Person";
else
return "Company";
}
}
public class Customer1Vm : BaseCustomerVm
{
public override string Name { get; set; }
public override int Number { get; set; }
public override bool IsPerson { get; set; }
}
To implement this, I have the following options:
Version 1:
public class Customer2Vm : BaseCustomerVm
{
public override string Name { get; set; }
public override int Number { get; set; }
public override bool IsPerson { get; set; }
// Further Properties
}
Version 2:
public class Customer2Vm : Customer1Vm
{
// Further Properties
}
In my search, I read ViewModels shouldn't derive from each other. This was also answerd in this post. My questions are:
Why should I not derive in this way?
What would be the correct way to handle sutch basics with no inheritance?

Inheritance shouldn't be an issue until you reach the point where you need to inherit from more than one (base) view model, i.e. if you have several different base view models that provide their own common base functionality.
Since you can't inherit from more than one class in C#, you then need to break out the common functionality into reusable components that you can inject into your view models.
But the only way you will be able to directly bind to some common properties that are defined in a class is to use inheritance and there is nothing wrong with inheriting from a chain of different base view model classes. In fact, this is a pretty common approach in my experience. Most of the types used in the view (Control, FrameworkElement, etc.) also do this.

As far as if Customer2Vm should derive from Customer1Vm; I think you want the classic inheritance question:
Does Customer2Vm have a "is-a" relationship with Customer1Vm?
Only you know; but based on the names I would doubt it. Sounds to me like they should both be deriving from BaseCustomerVm.
As far as whether or not you should be using inheritance at all; I would say that it largely seems OK here. If you wanted to avoid it (and strictly prefer composition) I would suggest making your VMs implement an ICustomerVm interface to get the properties; and then the consumer would use services to get the display text and image name. I would probably stick with what you have (assuming its more or less exactly what you've shown).

Implementing interfaces in C# .NET

Consider the following interface
public interface ICustomData
{
String CustomData { set; get; }
}
According to MSDN documentation, interfaces members are automatically public.
Lets say I now want to implement my interface:
public class CustomDataHandler : ICustomData
{
}
This would break at compile time, telling me that I have not implemented "CustomData"
This on the otherhand would work:
public class CustomDataHandler : ICustomData
{
public String CustomData { set; get; }
}
My question is: If the member of the interface is automatically public, why MUST I declare the implementation in the class? If the interface declaration is syntactically identical to the class declaration, why can the compiler not infer this automatically from my interface?
EDIT:
My reason for asking. Imagine a scenario where you are building data models, entities etc. I might code some interfaces to these models like so:
public interface IUserAccount
{
Guid Identity { set; get; }
String FirstName { set; get; }
String LastName { set; get; }
String EmailAddress { set; get; }
String Password { set; get; }
}
public interface IUserDataEntry
{
Guid DataIdentity { set; get; }
String DataName { set; get; }
String Data { set; get; }
}
It would be far simpler to construct the models like so:
public class UserAccount : IUserAccount
{
}
public class UserDataEntry : IUserDataEntry
{
}
public class Combined : IUserAccount, IUserDataEntry
{
}

An interface is not there to provide an implementation, it is there to define a contract. This then allows for different implementations to be built which implement it.

They may be syntactically identical, but they mean different things (i.e. they are not semantically identical).
In the interface, the syntax means that an implementing class must expose such a property, with get and set accessors implemented as it sees fit (either explicitly or implicitly). An interface merely defines the outward behaviour that a class must provide; it does not provide any implementation of that behaviour.
In the class, the syntax is an "auto-property", an implementation of the property defined by the interface, and the get and set accessors are implicitly converted into full implementations with a backing field. It looks something like this when it's compiled:
public class CustomDataHandler : ICustomData
{
private string customData;
public string CustomData
{
get
{
return customData;
}
set
{
customData = value;
}
}
}

You are implicitly implementing the interface. In this instance the method signatures of the class must match those of the interface (including accessibility). Ensuring that the methods are marked as public ensures that there are no surprises when looking at the class, for instance:
public class CustomDataHandler : ICustomData
{
String CustomData {get; set}
String PrivateCustomData {get;set;}
}
Even though both properties are declared the same, the CustomData property would be public by virtue of it being declared on the interface even though the declaration looks identical to that of PrivateCustomData. This would be inconsistent and lead to harder to maintain code.
If you do not wish to set the access modifier, you could explicitly implement the interface:
public class CustomDataHandler : ICustomData
{
String ICustomData.CustomData { set; get; }
}

The interface declaration is only specifying the behaviour which the interface defines. In your case, this is a property called CustomData which has a get and set (it is a read/write property) which is of type string.
The class which implements the interface needs to do exactly that - to specify the implementation.
Now in your case, you are using auto implemented properties { get; set; } which looks the same as the interface declaration, however you could also have a backing field and behaviour in your get or set methods.

Here's an example where the CustomData property is private in a derived class:
public class CustomDataHandler : ICustomData
{
private string CustomData { set; get; }
string ICustomData.CustomData { get; set; }
}
But this code compiles, because there is also an explicit implementation of the property.
So, the public modifier is not redundant in this case.

You must explicitly implement it because... You are not limited to implementing it that way. You could use a field, or do something else in your method. An interface is only a method contract that guaranty that this method exist.
public class CustomDataHandler : ICustomData
{
public String CustomData
{
get { return "None of your business!"; }
set { } // Decide to do nothing
}
}
The interface only guaranty this method will exist. Not what you're gonna do with it.
EDIT: As for your edit of your question, you probably seek to have a parent class instead of an interface if you want to implement the method only once for a collection of classes. However, while you can combine interface, you cannot combine parent classes. But, you can add interface at different point of a classes hierarchy.

Downcast on POCO classes

I have a group of POCO classes:
class ReportBase
{
public string Name { get; set; }
public int CustomerID { get; set; }
}
class PurchaseReport : ReportBase
{
public int NumberOfPurchases { get; set; }
public double TotalPurchases { get; set; }
public bool IsVip { get; set; }
}
class SaleReport : ReportBase
{
public int NumberOfSales { get; set; }
public double TotalSales { get; set; }
}
I have a web method to return ReportBase. The caller uses the return value to update UI(WPF) based on the actually type by downcasting and checking the type (one grid for sale and one for purchase). Someone suggested to use three web methods and each return the specific type.
I understand that downcast is in general against design principle by introducing if/else. Instead we should use virtual functions. But in POCO class, we don't really have virtual behaviors (only extra fields).
Are you for or against downcast in this case, why?

IMO it's all about intention. Returning just the base class doesn't say anything, especially as you return it only to save some key strokes. As a developer what do you prefer?
ReportBase GetReport() // if type==x downcast.
//or
PurchaseReport GetPurchaseReport()
SaleReport GetSalesReport()
What approach would you want to use to make the code more maintainable? Checking type and downcasting is an implementation detail after all and you probably have a method like this
public void AssignReport(ReportBase report)
{
//check, cast and dispatch to the suitable UI
}
What's wrong with this? It's lacking transparency, and this method should always know about what reports are needed by what UI elements. Any time you add/remove an element you have to modify this method too.
I think is much clear and maintainable something like this
salesGrid.DataSource=repository.GetSalesReport();
purchaseGrid.DataSource=repository.GetPurchaseReport();
than this
var report=repository.GetReport();
AssignReport(report); //all UI elements have their data assigned here or only 2 grids?
So I think that, POCO or not, I will favour the three web methods approach.

Object/Class Design Question

I have a class as follows :-
interface IFilterCondition
{
List<Name> ApplyFilter(List<Name> namesToFilter);
}
class FilterName : IFilterCondition
{
public NameFilterEnum NameFilterEnum{ get; set; }
public List<Name> ExcludeList { get; set; }
public char StartCharacter{ get; set; }
#region IFilterCondition Members
public List<Name> ApplyFilter(List<Name> namesToFilter)
{
switch (NameFilterEnum)
{
case NameFilterEnum.FilterFirstName:
// Check Exclude List
// Check Start Character
break;
case NameFilterEnum.FilterLastName:
// Check Exclude List only
break;
default:
break;
}
return namesToFilter;
}
#endregion
}
enum NameFilterEnum
{
None,
FilterFirstName,
FilterLastName
}
Note that only if it is flagged as a FilterFirstName then it will require the StartCharacter property.
Is the above correct or should I separate out FirstName filter and LastName filter as they require different properties? Coz I think in this instance, some business rules needs to be enforced when inputing data to this class.
Please advice,
Thanks

Enumerations are often a code smell that your design isn't quite right. In this case you could do better by refactoring the exclusion list functionality into a base class and then adding separate derived classes for the first and last name filters. The last name filter wouldn't do anything different from the generic filter but the first name filter would also check the start character.
interface IFilterCondition
{
List<Name> ApplyFilter(List<Name> namesToFilter);
}
abstract class FilterName : IFilterCondition
{
public List<Name> ExcludeList { get; set; }
public virtual List<Name> ApplyFilter(List<Name> namesToFilter)
{
// Check Exclude List
return namesToFilter;
}
}
class FilterFirstName : FilterName
{
public char StartCharacter{ get; set; }
public override List<Name> ApplyFilter(List<Name> namesToFilter)
{
namesToFilter = base.ApplyFilter(namesToFilter);
// Check Start Character
return namesToFilter;
}
}
class FilterLastName : FilterName
{
}

Looking at what you've got there it seems like it would make the most sense to have multiple classes which inherit from IFilterCondition defined that each fully implement their own version of ApplyFilter()- FirstNameFilter, LastNameFilter, PhoneNumberFilter, etc.
To save code, you can simply derive from a concrete implementation you create if and when you need to reuse similar logic to define the filter. For example you might have an [abstract] StartCharacterFilter that defines that character and truncates the list in its ApplyFilter() method then, FirstNameFilter would simply override ApplyFilter(), call the base implementation and pass the result to its own logic.

This seems like improper factoring. The filter apparently is strongly coupled with an enum value, and the type determines what specific criteria it needs, and the data values for that are jumbled into a single class.
It is more "pure" to have separate filter classes with only relevant data contained within each. The enum can probably be removed if you make that change.