Develop Reference

How can a class inherit from a parameterized version of itself?

I saw a C# class SomeClass that was defined like
public class SomeClass : IComparable<SomeClass>, IEquatable<SomeClass>
{
// ...
}
and I'm wondering how to translate that into English. The way I understand it seems logically impossible. How can a class inherit from a parameterized version of itself? Also, is this a common design pattern?

The key is to recognize that it's not inheriting from (or implementing) a parameterized version of itself, but rather inheriting from (or implementing) another class or interface, and using itself as a generic parameter for that target type.
For example, IComparable<T> says that there will be a CompareTo() method that takes an object of type T as a parameter. So by implementing IComparable<SomeClass> you're simply guaranteeing that a method with that signature will exist on this class:
public class SomeClass : IComparable<SomeClass>
{
public int CompareTo(SomeClass other)
{
//...
}
}
And yes, this is fairly common practice. Classes often implement the generic IComparable<> and IEquatable<> interfaces to show that they can be compared with other items of the same type. It's maybe also worth mentioning that enums in Java are declared as extending Enum<> of themselves--a pattern which is not common in C#, but does appear from time to time.

Translated in "English" it means: "Boy (or girl), you'd better be type-safe when implementing those interfaces, especially IComparable. Otherwise, you'll have to perform type casting, which I guess you don't want"
See the code below. SomeClass implemented IComparable and IComparable.
See differencies between implementations of CompareTo(object) and CompareTo(SomeClass).
namespace InterfacesStuff
{
internal class Program
{
private static void Main(string[] args)
{
var someClass1 = new SomeClass {ComparedValue = 1};
var someClass2 = new SomeClass {ComparedValue = 2};
//someClassObject defined as SomeClass
//object someClassObject = new SomeClass { ComparedValue = 2 };
//someClassObject defined as anything else but SomeClass
object someClassObject = 5;
int comparisonSomeClassBySomeClass = someClass1.CompareTo(someClass2);
int comparisonSomeClassByObject = someClass1.CompareTo(someClassObject);
}
}
public class SomeClass : IComparable, IComparable<SomeClass>, IEquatable<string>, IEquatable<int>,
IEquatable<double>
{
public int ComparedValue;
public int CompareTo(object obj)
{
var presumedSomeClassObject = obj as SomeClass;
if (presumedSomeClassObject != null)
{
if (ComparedValue <= ((SomeClass) obj).ComparedValue)
return -1;
}
return 0;
}
public int CompareTo(SomeClass other)
{
if (ComparedValue <= other.ComparedValue)
return -1;
return 0;
}
public bool Equals(double other)
{
throw new NotImplementedException();
}
public bool Equals(int other)
{
throw new NotImplementedException();
}
public bool Equals(string other)
{
throw new NotImplementedException();
}
}
}

It is not Inheriting, It is implementing the IComparable Interface. what is going on is
Someclass Implements the Icomparable and the IEquatable interface. Implementing an interface is like signing a contract stating you gaurentee that this class will implement the methods on an interface.
Icomparable msdn, IEquatable. If you look at the MSDN pages you can see that SomeClass gaurentees it will implement the methods in some fashion.
This is very common practice and it is many different names. The ones I hear most are programming by contract and Implementation over Inhertience. It lets you do a lot of cool things, like Dependency Injection, Proper Unit testing, better Generics. It does this because the compiler doesnt need to know the concrete class that your object is implementing. It just needs to know that it has certain functions on it. For further reading on this I would read Chapter one of the gang of four Design pattern book.
Wikipedia link Specifically the Introduction to Chapter one section

It doesn't really have to be convenient to express it in english for it to be valid code, although I'd probably read that as "SomeClass is comparable and equatable to itself". That doesn't really explain what's going on though, it's just a way of expressing it.
In C# types can be generic over categories of other types. Generic types are basically "type constructors". They take other types as parameters, and use them to construct new types. For instance, IEnumerable<int> and IEnumerable<string> are two completely different types. The non-generic version (IEnumerable) is a third one. In C# a type A can inherit ANY other type B as long as none of the following is true (I hope I didn't miss anything):
B is already a subtype of A
B is a class and A has already inherited another class
B is a struct
A is an interface but B is not
A is the same type as B
B is sealed
A is a struct and B is not an interface
This even makes the following code legal:
class Foo<T>
{
public T Value;
}
class Foo : Foo<int>
{
}
Foo and Foo<T> are different types, so there's no problem at all for one to inherit the other.
You can read more about generics here:
https://msdn.microsoft.com/en-us/library/ms379564(v=vs.80).aspx
And about inheritance here:
https://msdn.microsoft.com/en-us/library/ms173149.aspx

The code you posted does not inherit from any class. It is implementing certain so-called Interfaces. How to translate that snippet: "I guarantee that SomeClass will be Comparable and equatable with other SomeClass instances. I will provide definitions in this class on how to do that."
About specializing a class from some other class...
What you can do is something like this:
using System;
using System.Collections.Generic;
namespace ConsoleApp1
{
class Pet
{
protected string name;
public Pet(String name)
{
this.name = name;
}
}
class Dog : Pet
{
private List<String> tricks;
public Dog(String name, List<String> tricks):base(name)
{
this.tricks = tricks;
}
}
class Program
{
static void Main(string[] args)
{
List<string> tricks = new List<string>();
tricks.Add("sit");
tricks.Add("jump");
tricks.Add("bark");
Dog puppy = new Dog("Fido", tricks);
}
}
}
Dog inherits from Pet. Dog calls Pet's constructor at creation. Whatever name you pass into Dog constructor, it will forward it to Pet constructor.
Because what happens is that a subclass first calls the constructor of its superclass with the appropriate arguments. Then it runs its own constructor. Whatever is declared as public or protected in a class will be visible to its subclasses.
Therefore Dog will have name and also a list of tricks:
You achieve this kind of view with the "Locals" window.
I recommend that you read some tutorials on c# inheritance, interfaces and generics

How to restrict generic function to accept only some type of classes

I'm trying to do the following:
public class A
{
}
public class B
{
}
Somewhere along the project I want to have this:
public class C
{
public T func<T>(T obj) [where T can be either of class A or class B]
{
obj.x = 100;
return obj;
}
}
I've been trying:
public T func<T>(T obj) where T: A, B
but this gives me:
The type class constraint 'B' must come before any other constraint.
Can someone explain me how to make func accept only class A or class B?

Exactly as it's described in the question, this job is better handled by overload resolution:
public class C
{
public A func(A obj)
{
obj.x = 100;
return obj;
}
public B func(B obj)
{
obj.x = 100;
return obj;
}
}
But I understand that A and B may be placeholders for any number of types, and it could get tedious to account for them all. In that case, you'll need a common interface that's supported by each of your classes:
interface IBase
{
int x;
}
public class C
{
public IBase func(IBase obj)
{
obj.x = 100;
return obj;
}
}
Note that at this point we still have no need of generics. Additionally, you may need to support a number of types that won't all fit together under a common interface. In this case, still build the interface and put as many types with that interface as possible. If needed, build another interface for a few more types ... and so on... and then between interfaces and specific types you can handle things with overload resolution.

You need some kind of common base for both the classes, either have them implement the same interface as the below code or have them inherit from same class. You can not have a generic constrained to 2 types.
public interface IFooBar
{
void DoThis();
}
public class Foo : IFooBar
{
public void DoThis()
{
//Do something
}
}
public class Bar : IFooBar
{
public void DoThis()
{
//Do something
}
}
public class C
{
public T func<T>(T obj) where T : IFooBar
{
obj.DoThis();
return obj;
}
}

The generics classes are just like any other class, you can't (and shouldn't) have multiple inheritance of classes, you can inherit one class and multiple interfaces.
in your case you should apply an interface on both classes and restrict the generics on that interface.
you can see some documentation in:
Constraints on Type Parameters (C# Programming Guide)

interface IMarkerInterface{} // there is a such pattern called marker
// interface . No need to have methods if there
// is no need for, A and B can just implement it
public class A: IMarkerInterface
{
}
public class B: IMarkerInterface
{
}
public class C
{
public T func<T>(T obj).Where T:IMarkerInterface
{
obj.x = 100;
return obj;
}
}

public T func<T>(T obj) where T: A, B this means T should extend both A and B , but multiple inheritance is not valid in C# ,so it won't work.
You could do one of the following though :
you could make A and B have a common parent via an interface or an abstract class , but that would be code modification.
since both A and B have a default no-arg constructor you could use where T: new().
Also, you can not do obj.x = 100; as there is no way to guarantee thatT will have a instance variable x.

C#: "Cannot create an instance of the static class"

I'm in the process of converting some Java code to C# and stumbled across the following curious thing:
public interface IActivation {
public abstract double func(double inputput);
public static class S1 : IActivation {
public double func(double input) {
if (input > 0) return 1.0;
return 0.0;
}
}
}
SomewhereElse (usage):
protected IActivation activation = new IActivation.S1();
Looking at the original code, it's clear what the intention of this was:
Declare an interface and nested within it several static implementations of that interface (the code contains other implementations of IActivation, e.g. "S2", "S3" etc. which were omitted here).
The typical usage scenario for this was to assign a variable to one specific implementation of that interface. Also, by the way you'd need to instantiate that variable, it's perfectly clear where those specific implementations belong to - in a manner of speaking, the nested declaration would further increase the readability of the code
(e.g. new IActivation.S1(); makes it clear that S1 is a specific implementation of IActivation).
Interestingly, C# does not like the way the whole thing is defined: "Cannot create an instance of the static class 'IActivation.S1". Does anyone know a way of how to refactor that code so that 1. and 2. would be preserved?

In Java, a static inner class has no implicit access to the members of its enclosing type. In C#, all nested types have no such access to their parent type's members; there is no modifier you need to add in C# to trigger this behavior.
In C#, static classes are abstract sealed, so they cannot be created nor derived -- this is not the same meaning as in Java. Additionally, interfaces cannot contain type declarations of their own.
Try something like this:
public interface IActivation {
double Func(double inputput);
}
public class S1 : IActivation {
public static readonly S1 Instance = new S1();
private S1() { }
public double Func(double input) {
if (input > 0) return 1.0;
return 0.0;
}
}
If your goal is to provide default implementations in some "readable" way (though I dispute that IActivator.S1() is inherently more readable...) then you could create a static factory class:
public static class Activator
{
public static S1 S1
{
get
{
return S1.Instance;
// Or you could do this if you make the S1 constructor public:
// return new S1();
}
}
}
However, I dispute the claim that this is more readable or helpful. Visual Studio will, when constructing an object in the context of a particular type, display all of that type's subtypes. So if you do this (| represents the cursor):
IActivator foo = new |
You should get a neat list of all of the classes in your current scope that implement IActivotor.

Do not mark your class as static.

If IActivation does not have to be an interface, you can turn it into an abstract class
public abstract class IActivation
{
public abstract double func(double inputput);
public class S1 : IActivation
{
public override double func(double input)
{
if (input > 0) return 1.0;
return 0.0;
}
}
}
This changes the actual meaning of the code, but allows you to say
var s1 = new IActivation.S1();
Update The main issue I can think of is if you have a class that extends something else and implements this interface it won't work (you can't inherit from two classes). You could then create an interface and an abstract class that implements the abstract class but that's getting a little silly.
Another option is
public interface IActivation {
// ...
}
public class Activation {
public class S1 : IActivation {
// ...
}
}
The advantage is you keep IActivation as an interface, but you have another class littering your namespace.
In both cases, you haven't done a direct port from Java.

The error message itself is clear, the S1 class cannot be static since you are creating an instance of it. Remove the static keyword from S1. Also, the access modifier and abstract modifier are invalid in an interface declaration.
In C#, interfaces cannot declare inner types.
My suggestion here is to use the Factory pattern to get the correct instances instead of nesting types in your interface (this increases coupling/dependencies).
interface IActivation
{
double func(double inputput);
}
public static class ActivationFactory
{
IActivation GetImplA()
{
return new ImplA();
}
IActivation GetImplB()
{
return new ImplB();
}
}
class ImplA : IActivation { }
class ImplB : IActivation { }

use sigleton pattern for each S'i' implementation and tear appart interface and implementation as described above by cdhowie
It seems you don't need factory - unless your S'i' instances have own state?

C# Interfaces: Is it possible to refer to the type that implements the interface within the interface itself?

What I basically wish to do is design a generic interface that, when implemented, results in a class that can behave exactly like T, except that it has some additional functionality. Here is an example of what I'm talking about:
public interface ICoolInterface<T>
{
T Value { get; set; }
T DoSomethingCool();
}
public class CoolInt : ICoolInterface<int>
{
private int _value;
public CoolInt(int value)
{
_value = value;
}
public int Value
{
get { return _value; }
set { _value = value; }
}
public int DoSomethingCool()
{
return _value * _value;
// Ok, so that wasn't THAT cool
}
}
And this is all well and good, but in order to use CoolInt, I need to do something like this:
CoolInt myCoolInt = new CoolInt(5);
int myInt = myCoolInt.Value;
I'd much rather, in terms of assignment at least, that CoolInt works just like int. In other words:
CoolInt myCoolInt = 5;
int myInt = myCoolInt;
To achieve this, I added these two conversion operators to my CoolInt class:
public static implicit operator CoolInt(int val)
{
return new CoolInt(val);
}
public static implicit operator int(CoolInt obj)
{
return obj.Value;
}
Works awesomely. Now, I would prefer it if I could add these two overloads to the interface, so that implementers of the interface are forced to implement these operators. The problem is, the prototypes of these operators refer directly to CoolInt.
C# has a lot of "placeholder" names for things that are implicitly defined or have yet to be defined. The T that is conventionally used in generic programming is one example. I suppose the value keyword, used in Properties, is another. The "this" reference could be considered another. I am hoping that there's another symbol I can use in my interface to denote "the type of the class that is implementing this interface", e.g. "implementer".
public static implicit operator implementer(int val)
{
return new IntVal(val);
}
public static implicit operator int(implementer obj)
{
return obj.Value;
}
Is this possible?

Why don't you create an abstract class? This way you can build some "default" functionality into your class.

Sadly no :(
C# doesn't do well when it comes to operator overloading (This is one example, another is generic constraints on certain operator types).

Why not use extension methods instead? That lets you "add" methods to int without having to use a different type.

This is probably the closest you can get using an abstract base type, but sadly even this has an issue with one of the implicit operators and you have to do:-
CoolInt x = (CoolInt)5;
int j = x;
Close enough?
// Slightly sneaky, we pass both the wrapped class and the wrapping class as type parameters to the generic class
// allowing it to create instances of either as necessary.
public abstract class CoolClass<T, U>
where U : CoolClass<T, U>, new()
{
public T Value { get; private set; }
public abstract T DoSomethingCool();
// Non-public constructor
protected CoolClass()
{
}
public CoolClass(T value)
{
Value = value;
}
public static implicit operator CoolClass<T, U>(T val)
{
return new U() { Value = val};
}
public static implicit operator T(CoolClass<T, U> obj)
{
return obj.Value;
}
}
public class CoolInt : CoolClass<int, CoolInt>
{
public CoolInt()
{
}
public CoolInt(int val)
: base(val)
{
}
public override int DoSomethingCool()
{
return this.Value * this.Value; // Ok, so that wasn't THAT cool
}
}

It would be helpful if, at least for interfaces, one could declare that a class implements an interface in terms of an object; this would be especially cool if there was an "interface" generic type constraint. Then one could, for example, do something like (VB syntax)
Class Foo(Of T as Interface)
Implements T via Bar ' Declares variable 'bar' of type T
Sub DoSomething
' Does something
End Sub
End Class
and then cast a Foo(of T) to a T and have it behave like a T. Maybe someone from MS can stumble on the idea and pass it on?
I should note, btw, a nice pattern similar to your ICoolInterface:
public interface ISelf<T>
{
T Self { get;}
}
public interface IFoozle
{
... definitions for IFoozle
}
public interface IFoozle<T> : ISelf<T> , IFoozle;
{
/* Empty except for above declarations */
}
... similarly define IWoozle and IWoozle<T&gt etc.
Then one can declare a field which can implement IWoozle and IFoozle, and inherits from BoozleBase (which implements neither), via:
IWoozle<IFoozle<BoozleBase>> myField1;
or
IFoozle<IWoozle<BoozleBase>> myField2;
Note that the above two types can be cast to each other, or to types which also contain other interfaces. If one only needs to pass a variable meeting multiple constraints to a method, one can obtain such a thing more easily by using a generic method. Unfortunately, there's no way to store an object of unknown type in a field in such a way that it can be passed to a generic function with multiple constraints.

Is the C# "explicit implementation" of the interface present in Java?

In C#, if you have two base interfaces with the same method (say, F()) you can use explicit implementation to perform different impl. for F(). This alloes you to differently treat the object, corresponding to the current point of view: as IMyInterface1 or IMyInterface2. Is this possible in Java?

No, there's nothing like C#'s explicit interface implementation in Java.
On the plus side, Java has covariant return types, so if you want to provide a more strongly typed implementation than the interface specifies, that's okay. For instance, this is fine:
interface Foo
{
Object getBar();
}
public class Test implements Foo
{
#Override
public String getBar()
{
return "hi";
}
}
C# wouldn't allow that (prior to C# 9, which now supports covariant return types) - and one of the ways around it is typically to implement the interface explicitly and then have a more specific public method (usually called by the interface implementation).

You can achieve similar effect using the mechanism of anonymous interface implementation in Java.
See example:
interface Foo {
void f();
}
interface Bar {
void f();
}
public class Test {
private String foo = "foo", bar = "bar";
Foo getFoo() {
return new Foo() {
#Override
public void f() {
System.out.println(foo);
}
};
}
Bar getBar() {
return new Bar() {
#Override
public void f() {
System.out.println(bar);
}
};
}
public static void main(String... args) {
Test test = new Test();
test.getFoo().f();
test.getBar().f();
}
}

You can only do this if the methods are overloaded.
If you have two method which are expected to do different things, they should have different names IMHO.

No and it should never be present in Java. It's just another bone to throw at people who can't be bothered with good design.
Explicit implementation of an interface should never be needed or used. There are better ways to solver the problem that this tries to solve.