This is class design question.
I have main abstract class
public abstract class AbstractBlockRule
{
public long Id{get;set;}
public abstract List<IRestriction> Restrictions {get;};
}
public interface IRestriction{}
public interface IRestriction<T>:IRestriction where T:struct
{
T Limit {get;}
}
public TimeRestriction:IRestriction<TimeSpan>
{
public TimeSpan Limit{get;set;}
}
public AgeRestriction:IRestriction<int>
{
public int Limit{get;set;}
}
public class BlockRule:AbstractBlockRule
{
public virtual List<IRestriction> Restrictions {get;set;}
}
BlockRule rule=new BlockRule();
TimeRestriction t=new TimeRestriction();
AgeRestriction a=new AgeRestriction();
rule.Restrictions.Add(t);
rule.Restrictions.Add(a);
I have to use non-generic Interface IRestriction just to avoid specifying generic type T in main abstract class. I'm very new to generics. Can some one let me know how to better design this thing?
Your approach is typical (for example, IEnumerable<T> implements IEnumerable like this). If you want to provide maximum utility to consumers of your code, it would be nice to provide a non-generic accessor on the non-generic interface, then hide it in the generic implementation. For example:
public abstract class AbstractBlockRule
{
public long Id{get;set;}
public abstract List<IRestriction> Restrictions { get; set; }
}
public interface IRestriction
{
object Limit { get; }
}
public interface IRestriction<T> : IRestriction
where T:struct
{
// hide IRestriction.Limit
new T Limit {get;}
}
public abstract class RestrictionBase<T> : IRestriction<T>
where T:struct
{
// explicit implementation
object IRestriction.Limit
{
get { return Limit; }
}
// override when required
public virtual T Limit { get; set; }
}
public class TimeRestriction : RestrictionBase<TimeSpan>
{
}
public class AgeRestriction : RestrictionBase<TimeSpan>
{
}
public class BlockRule : AbstractBlockRule
{
public override List<IRestriction> Restrictions { get; set; }
}
I also showed using a base restriction class here, but it is not required.
The runtime treats IRestriction<TimeSpan> and IRestriction<int> as different distinct classes (they even have their own set of static variables). In your case the only classes common to both IRestriction<TimeSpan> and IRestriction<int> in the inheritance hierarchy are IRestriction and object.
So indeed, having a list of IRestriction is the only sensible way to go.
As a side note: you have a property Limit in there that you might want to access regardless of whether you're dealing with an IRestriction<TimeSpan> or IRestriction<int>. What I would do in this case is to define another property object Limit { get; } on IRestriction, and hide it in the actual implementation. Like this:
public interface IRestriction
{
object Limit { get; }
}
public interface IRestriction<T> : IRestriction
where T : struct
{
new T Limit { get; set; }
}
public class TimeRestriction : IRestriction<TimeSpan>
{
public TimeSpan Limit { get; set; }
// Explicit interface member:
// This is hidden from IntelliSense
// unless you cast to IRestriction.
object IRestriction.Limit
{
get
{
// Note: boxing happens here.
return (object)Limit;
}
}
}
This way you can access Limit as object on all your IRestriction when you don't care what type it is. For example:
foreach(IRestriction restriction in this.Restrictions)
{
Console.WriteLine(restriction.Limit);
}
Interfaces are contracts that need to be followed by the entity that implements the contract.
You have created two contract with the same name IRestriction
As far as I can see, what you are basically may need is a flag for classes that can be restricted, which should implement the IRestriction non-generic interface.
The second interface seems to be restrictable objects that also contain a limit property.
Hence the definition of the second IRestriction interface can be ILimitRestriction or whatever name suits your business needs.
Hence ILimitRestriction can inherit from IRestriction which would mark classes inheriting ILimitRestriction still objects of IRestriction
public abstract class AbstractBlockRule
{
public long Id{get;set;}
public abstract List<IRestriction> Restrictions {get;};
}
public interface IRestriction{}
public interface IRestrictionWithLimit<T>:IRestriction where T:struct
{
T Limit {get;}
}
public TimeRestriction:IRestrictionWithLimit<TimeSpan>
{
public TimeSpan Limit{get;set;}
}
public AgeRestriction:IRestrictionWithLimit<int>
{
public int Limit{get;set;}
}
public class BlockRule:AbstractBlockRule
{
public virtual List<IRestriction> Restrictions {get;set;}
}
Related
tl;dr: I want the list List<ComponentDefinition> in the CellObjectDefinition class to be able to be checked with a type check ICellObjectDefinition<IComponentDefinition>.
ComponentDefinition is unknown at runtime and must therefore be testable with IComponentDefinition.
I have the following class:
public interface IComponentDefinition {}
public class ComponentDefinition : IComponentDefinition {}
public interface ICellObjectDefinition<TCDef>
{
public List<TCDef> Components { get; set; }
}
public class CellObjectDefinition : ICellObjectDefinition<ComponentDefinition>
{
public List<ComponentDefinition> Components { get; set; } = new();
}
I would have liked to keep the type ComponentDefinition in this list as the elements are added dynamically with reflection elsewhere. I want to validate the elements with their associated interfaces.
I don't quite understand why the list doesn't match the interface when I check the list filled with ComponentDefinition elements with ICellObjectDefinition<IComponentDefinition>.
Even an interface without a generic type does not work:
public interface ICellObjectDefinition<IComponentDefinition>
{
public List<IComponentDefinition> Components { get; set; }
}
Here is an executable sample code: https://dotnetfiddle.net/tpiNgJ
Depended on the actual use case you can make your interface covariant:
public interface ICellObjectDefinition<out TCDef> : IObjectDefinition
{
public IReadOnlyCollection<TCDef> Components { get; }
}
Which will require some implementation changes (using explicit interface implementation):
public partial class CellObjectDefinition : ObjectDefinition, ICellObjectDefinition<ComponentDefinition>
{
IReadOnlyCollection<ComponentDefinition> ICellObjectDefinition<ComponentDefinition>.Components => Components; // explicitly implement the interface
public List<ComponentDefinition> Components { get; set; } = new();
}
Full running code - at dotnetfiddle.
I am faced with a C# design problem that C#'s limitations are making hard to achieve. I need some sort of design pattern/strategy to rescue me.
I must create the archetypical set of abstract shape classes: Base class Shape with derived classes LineShape, RectShape, etc. Specific implementations will derive from these. The problem is that I really need to use classes here, not interfaces and this is forcing me to duplicate a lot of code.
To illustrate:
public abstract class Shape
{
public abstract int Id { get; } // Unique ID
public abstract string Name { get; set; } // Shape name. Defaults to the type of shape
public abstract bool IsLocked { get; set; } // May the user change this shape in any way?
}
public abstract class LineShape : Shape
{
public abstract Point P1 { get; set; }
public abstract Point P2 { get; set; }
}
public abstract class CircleShape : Shape
{
public abstract Point Center { get; set; }
public abstract double Radius { get; set; }
}
When I start creating the derived implementations (LineImpl, CircleImpl, etc), I find that the implementations of the Shape functions are identical for all the Impl classes, yet specific enough that I cannot implement them in the abstract Shape class itself.
So I need to find a way to share a common implementation of these function in my derived hierarchy.
In other words LineImpl must derive from LineShape. CircleImpl must derive from CircleShape, etc. I cannot find a way to insert a ShapeImpl in there to handle the boiler plate stuff. So I am forced to implement all those Shape functions over and over again, once in each Impl shape type.
I tried using generics to get my way out of this but unfortunately a generic class cannot specify its base class with a generic argument. In other words, the following approach (which I might do in C++) does not work in C#
public class ShapeImpl<TBase> : T where T : Shape { ... boiler plate implemented here)...}
public class LineImpl : ShapeImpl<LineShape> { }
public class CircleImpl : ShapeImpl<CircleShape> { }
So I am at a loss. Is there some C# trick or design pattern that can get me out of this? Or am I forced to implement the same functions multiple times?
yet specific enough that I cannot implement them in the abstract Shape class itself.
You also mentioned:
I find that the implementations of the Shape functions are identical for all the Impl classes
I think that this is classic case of over-thinking for future implementation. if you say- the implementation is identical for all classes, I wouldn't bother too much over thinking for something in the future that may never arrive.
But, if you insist, you may implement it in the following way:
public abstract class Shape
{
public abstract int Id { get; } // Unique ID
public abstract string Name { get; set; } // Shape name. Defaults to the type of shape
public abstract bool IsLocked { get; set; } // May the user change this shape in any way?
public abstract void Foo();
}
public abstract class SepcificShape : Shape
{
protected virtual void FooSpecific()
{
Console.WriteLine("Specific Implementation");
}
}
public abstract class LineShape : SepcificShape
{
public abstract Point P1 { get; set; }
public abstract Point P2 { get; set; }
}
public class LineImp : SepcificShape
{
public override int Id { get; }
public override string Name { get; set; }
public override bool IsLocked { get; set; }
public override void Foo()
{
base.FooSpecific();
}
}
The only way to achieve something similar to multiple inheritance in C# I can think of would be to use default interface implementations, e.g. like this:
interface IShapeSdk
{
string GetNameSdk() => "Shape SDK name";
}
abstract class Shape
{
public abstract string GetName();
}
class ShapeImpl : Shape, IShapeSdk
{
public override string GetName()
{
return ((IShapeSdk)this).GetNameSdk();
}
}
This way all shapes will inherit from Shape, but only the external-SDK-shapes will inherit the common logic defined in IShapeSdk.
Not the cleanest approach, and a lot of C# developers are against the usage of this relatively new feature (which by the way is available only in C# 8 and above and .NET Core 3.0 and above).
I have the following interface I want to implement in a class:
public interface IAgro {
AgroState agroState { get; }
}
The problem is that instead of implementing AgroState in the class using the interface I want my property to implement a different class which inherits from AgroState
public class E1_AgroState : AgroState
{
...
}
public class BasicWalkingEnemy : Entity, IAgro
{
public E1_AgroState agroState { get; }
}
This is something I am used to do in Swift with protocols, for example, but C# compiler complains with
'BasicWalkingEnemy' does not implement interface member 'IAgro.agroState'. 'BasicWalkingEnemy.agroState' cannot implement 'IAgro.agroState' because it does not have the matching return type of 'AgroState'. [Assembly-CSharp]csharp(CS0738)
For now one solution I found is doing it like:
public class BasicWalkingEnemy : Entity, IAgro
{
public AgroState agroState { get { return _agroState; } }
public E1_AgroState _agroState { get; private set; }
}
But I think that is very inelegant.
Is there a better solution to my problem?
Typically the way you'd do this is with explicit interface implementation so that anyone who only knows about your object via IAgro will just see AgroState, but any code that knows it's working with BasicWalkingEnemy will get E1_Agrostate:
// Note: property names changed to comply with .NET naming conventions
public class BasicWalkingEnemy : Entity, IAgro
{
// Explicit interface implementation
AgroState IAgro.AgroState => AgroState;
// Regular property
public E1_AgroState AgroState { get; private set; }
}
Is it possible to prevent using abstract classes as property type?
I have a abstract base class being inherited in an abstract class with generic type, which in turn is inherited in classes with defined types. Is it possible to "lock down" the abstract class with generic type, so it's not possible to use it as a property in other classes?
Here's an approximation of my situation. I want to prevent the possibility of creating properties like doubleFoo2. The Foo<T> should only be able to be inherited in other classes, and not be able to be used as a type directly.
Since I'm validating PropertyType of properties and their base types, this lead to me making a mistake it took me a while to find. Here's a test of the code: https://dotnetfiddle.net/OMHmGv
public abstract class FooBase
{
// Various generic properties and methods
}
public abstract class Foo<T> : FooBase
{
public Type ValueType { get { return typeof(T); } }
public abstract T Value { get; set; }
}
public class DoubleFoo : Foo<double>
{
public override double Value { get; set; }
}
public class FooHandler
{
public DoubleFoo doubleFoo1 { get; set; }
public Foo<double> doubleFoo2 { get; set; }
}
Not only it's impossible, it goes against one of the three basic principles of object oriented programming - and I'm talking, of course, about polymorphism.
Giving up polymorphism is giving up object oriented programming altogether.
The point is that a reference of a type can actually refer to an instance of any type deriving from the reference type.
Polymorphism is what makes the following code line is perfectly valid (even though not very useful):
object s = "the type is actually a string but the reference is of type object";
Edit: Like what #Zohar Peled said, it defeats the purpose of polymorphism, restricting usage based on namespace or assembly is your only way.
If the DoubleFoo and its child classes are created in a seperate assembly, you may use the
internal
modifier instead of
public
for both FooBase and Foo classes to prevent other assemblies from access them.
If you have to use this DoubleFoo in the same assembly, you can try putting the base classes in the different namespace to hide the base implementation classes.
An example would be:
Inside FooOfT.cs
namespace FooTester.DoubleFoo.Foo
{
public abstract class FooBase
{
// Various generic properties and methods
}
public abstract class Foo<T> : FooBase
{
public Type ValueType { get { return typeof(T); } }
public abstract T Value { get; set; }
}
}
Inside DoubleFoo.cs
using FooTester.DoubleFoo.Foo
namespace FooTester.DoubleFoo
{
public class DoubleFoo : Foo<double>
{
public override double Value { get; set; }
}
}
inside FooHandler.cs
using FooTester.DoubleFoo
namespace FooTester
{
public class FooHandler
{
public DoubleFoo doubleFoo1 { get; set; }
// public Foo<double> doubleFoo2 { get; set; } Cannot access Foo<T> class
}
}
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.