Develop Reference

How to require subtypes of an abstract class to implement a static instantiator?

public abstract class A
{
// constructors omitted
public abstract A Create(SomeData data);
}
public class B : A
{
// constructors omitted
public override A Create(SomeData data)
{
return new B(data);
}
}
What I want is to be able to make the Create method static, so that I can get an instance of B without having to create a useless instance with an empty constructor. (If you're wondering why, A is actually a generic type of the form A<TFoo, TBar>, where TBar corresponds to the derived types. As we all know, you can't instantiate a generic type using a constructor that takes any arguments.)
I am already aware that static methods are decoupled from the object hierarchy, only relying on the name of the type. That means I can't have Create as an abstract method that I force all descendants to implement. Is there another way I can implement this pattern?

Something like this might work, depends on your requirements
public abstract class A
{
public string Data { get; set; }
public static T Create<T>(string data) where T : A, new()
{
return new T() { Data = data };
}
}
public class B : A { }
then can do
A foo = A.Create<B>("foo");

There is simply no way to do this. Inheritance is based off of instance methods in C# and has no equivalent feature for static methods. Another way to implement this pattern though is to require a lambda in lieu of a static method.
For example (you mentioned the actual type was A<TFoo, TBar>)
void UseIt<TFoo, TBar>(A<TFoo, TBar> p, Func<SomeData, TBar> func) {
TBar b = func();
...
}
The consumer doesn't care if Create is static, instance or even called create. Generally all they care about is having a function which takes a SomeData and returns a TBar. Delegates fit this pattern exactly.

Derived Class Calling static method of base class in its own static method

I have read through the follow SO articles
C#: How do I call a static method of a base class from a static method of a derived class?
Can I have a base class where each derived class has its own copy of a static property?
What's the correct alternative to static method inheritance?
All seem very close to my question and have good answers, but they do not seem to answer my question other than to say that I need to make the method non-static.
an example:
abstract public class baseClass
{
private static List<string> attributeNames = new List(new string {"property1","property2"});
// code for property definition and access
virtual public static bool ValidAttribtue(string attributeName)
{
if (attributeNames.Contains(attributeName))
return true;
else
return false;
}
}
class derivedA : baseClass
{
private static List<string> attributeNames = new List(new string {"property3","property4"});
// code for property definition and access
public static override bool ValidAttribute(string attributeName)
{
if (attributeNames.Contains(attributeName))
{
return true;
}
else
{
return base.ValidAttribute(attributeName);
}
}
}
class derivedB : baseClass
{
private static List<string> attributeNames = new List(new string {"property10","property11"});
// code for property definition and access
public static override bool ValidAttribute(string attributeName)
{
if (attributeNames.Contains(attributeName))
{
return true;
}
else
{
return base.ValidAttribute(attributeName);
}
}
}
derivedA would have properties 1,2,3,4 while derivedB would have properties 1,2,10,11.
The list of properties seems to be a class specific value and can not be changed at any point. I would think it then would be static.
Is my design wrong in the sense that I am trying to use static methods when they should not be?
The above example makes me think that inheritance of static methods would be needed, yet it seems that trying to do this is a design flaw. Can anyone help me to understand what is wrong with coding or structuring classes in this manner?

Is my design wrong in the sense that I am trying to use static methods when they should not be?
Yes. Aside from anything else, you're trying to declare a static method as virtual (and then override it), which isn't allowed. You're also trying to declare a class called base, when that's a keyword.
Static methods simply aren't polymorphic. The basis of polymorphism is that the execution time type of the instance involved can be different to the compile-time type of the expression, and the implementation is chosen on the basis of the execution time type. That concept doesn't make sense for static methods as there is no instance.
Now of course you can make a static method in a derived class call a static method in the base class - but there won't be any polymorphism anywhere.
As a side note, all of your methods could be written in a more readable way:
// Base class implementation
return attributeNames.Contains(attributeName);
// Derived class implementations
return attributeNames.Contains(attributeName) ||
BaseClass.ValidAttribute(attributeName);

C# Virtual & Override Keywords

I thought I had this nailed, and then I go and look at some source at work and am left wondering why there are so many contradictions in what I read from msdn and what I am seeing in source....
My understanding is that the virtual keyword can be used in method declarations to allow any deriving classes to override it.
The override keyword would then need to be used in the derived class when implementing the superclass' virtual method....
For example:
public abstract class A
{
public virtual string GetName();
}
public class B:A
{
//assume there are some defined properties.
public override string GetName()
{
return FirstName;
}
}
I have a few questions:
1) Is it really necessary to define a method as virtual if it has no implementation? Surely it can just be overwritten in the subclass without the use of virtual and override?
2) If (1) is incorrect, am I right in thinking that every virtual method must be overridden in the subclass using it....
EDIT:
You're right my code will not compile... I want to know why....I uinderstand your answers but then I saw this:
public abstract class RequestHandler<TRequest, TResponse> : RequestHandler, IRequestHandler<TRequest>, IRequestHandler, IDisposable, ITypedRequestHandler
where TRequest : global::Agatha.Common.Request
where TResponse : global::Agatha.Common.Response, new()
{
protected RequestHandler();
public virtual void AfterHandle(TRequest request);
public virtual void BeforeHandle(TRequest request);
public override Response CreateDefaultResponse();
public TResponse CreateTypedResponse();
public override Response Handle(Request request);
public abstract Response Handle(TRequest request);
}
The above doesnt cause the compiler to complain...

Firstly the above code is invalid. A virtual method still has to have a body with a default implementation. to do what you have done above you would need to use the abstract keyaord instead of virtual.
abstract means that there is no method body provided but that any class deriving from it must implement this method (unless it is abstract too).
I think this pretty much answers your questions....
If it has no implementation then it cannot be virtual, it must be abstract. If it has an implementation that just does nothing then that must be implemented.
The whole point of a virtual class is that it has default behaviour so you can choose whether or not to override it. If it were abstract then you would have to override it (unless you were deriving another abstract class).

Is it really necessary to define a method as virtual if it has no implementation?
You can make the method abstract (it will implicitly make it virtual).
Surely it can just be overwritten in the subclass without the use of virtual and override?
If you just "overwrite" it without explicitly overriding it, it won't be the same method, and calling the method on a variable of the base class won't call the derived method (it won't participate in polymorphism). You would just be "hiding" the method of the base class (the compiler actually warns you about this, if it's really what you want to do you must use the new modifier.)
An example will make it clearer:
class B
{
public virtual void M() { Console.WriteLine("B.M") };
}
class D1 : Base
{
// Hides the base method
public new void M() { Console.WriteLine("D1.M") };
}
class D2 : Base
{
// Overrides the base method
public override void M() { Console.WriteLine("D2.M") };
}
...
D1 d1 = new D1();
d1.M(); // Prints "D1.M"
B b1 = d1;
b1.M(); // Prints "B.M", because D1.M doesn't override B.M
D2 d2 = new D1();
d2.M(); // Prints "D2.M"
B b2 = d2;
b2.M(); // Also prints "D2.M", because D2.M overrides B.M
If (1) is incorrect, am I right in thinking that every virtual method must be overridden in the subclass using it....
No, only if it's abstract... a virtual method can have an implementation, and in that case derived classes are not forced to override it.

1) Is it really necessary to define a method as virtual if it has no implementation? Surely it can just be overwritten in the subclass without the use of virtual and override?
As said in other answers, virtual methods need to have implementations. You are confusing it with abstract.
If you were asking whether virtual methods which do have an implementation need to be declared virtual: In C#, yes, it is necessary. In Java, you can override any old method. It was a C# design decision to require overriding to be specifically allowed with the virtual keyword, so that methods cannot be overridden unless intended by the programmer.
If the programmer has not expressed intent by not using virtual, you can still "override" methods, with the new keyword. However, this works a bit differently. Hopefully this code will help illustrate the concept:
class Program
{
static void Main(string[] args)
{
var baseC = new BaseClass();
var extC = new ExtClass();
var lazyC = new LazyClass();
Console.WriteLine(baseC.NewMethod());
Console.WriteLine(baseC.VirtualOverrideMethod());
Console.WriteLine("---");
Console.WriteLine(extC.NewMethod());
Console.WriteLine(extC.VirtualOverrideMethod());
Console.WriteLine("---");
Console.WriteLine(((BaseClass) extC).NewMethod());
Console.WriteLine(((BaseClass) extC).VirtualOverrideMethod()); // Redundant typecast
Console.WriteLine("---");
Console.WriteLine(lazyC.VirtualOverrideMethod());
Console.ReadKey();
}
public class BaseClass
{
public BaseClass()
{
}
public string NewMethod()
{
return "NewMethod of BaseClass";
}
public virtual string VirtualOverrideMethod()
{
return "VirtualOverrideMethod of BaseClass";
}
}
class ExtClass : BaseClass
{
public new string NewMethod()
{
return "NewMethod of ExtClass";
}
public override string VirtualOverrideMethod()
{
return "VirtualOverrideMethod of ExtClass";
}
}
class LazyClass : BaseClass
{
}
}
Output:
NewMethod of BaseClass
VirtualOverrideMethod of BaseClass
---
NewMethod of ExtClass
VirtualOverrideMethod of ExtClass
---
NewMethod of BaseClass
VirtualOverrideMethod of ExtClass
---
VirtualOverrideMethod of BaseClass
2) If (1) is incorrect, am I right in thinking that every virtual method must be overridden in the subclass using it....
Not at all. virtual is a way of saying, "it's okay if you want to override this method". In fact, I included LazyClass in my code above to show this.
The above doesnt cause the compiler to complain...
I haven't used interfaces much, but that looks like one. In my code, if I change
class ExtClass : BaseClass
{
public new string NewMethod()
{
return "NewMethod of ExtClass";
}
public override string VirtualOverrideMethod()
{
return "VirtualOverrideMethod of ExtClass";
}
}
to:
class ExtClass : BaseClass
{
public new string NewMethod()
{
return "NewMethod of ExtClass";
}
public override string VirtualOverrideMethod()
{
return "VirtualOverrideMethod of ExtClass";
}
}
I get:
error CS0501: 'OverrideTest.Program.ExtClass.VirtualOverrideMethod()' must declare a body because it is not marked abstract, extern, or partial
From Visual Studio 2010. The same goes for the virtual method of my BaseClass.

The need for virtual is dictated by polymorphism. Think about what happens when you redefine a method in a subclass using new:
class Parent
{
void Foo() { Console.WriteLine("Parent"); }
virtual void Bar { Console.WriteLine("Parent"); }
}
class Child : Parent
{
new void Foo() { Console.WriteLine("Child"); } // another method Foo
override void Bar { Console.WriteLine("Child"); }
}
var child = new Child(); // a Child instance
var parent = (Parent)child; // same object, but statically typed as Parent
c.Bar(); // prints "Child"
p.Bar(); // again, prints "Child" -- expected virtual behavior
c.Foo(); // prints "Child"
p.Foo(); // but this prints "Parent"!!
For this reason, classes that are intended to be derived from (i.e. not sealed) should always mark the methods that can be overridden as virtual -- otherwise there will be confusing runtime behavior like above. There's no difference if the parent implementation actually does anything or not; the point is that it behaves differently.

ok, by declaring the method as virtual (and not wishing to override the method in the subclass), you'd be entering the world of method hiding if you were to introduce a method with the same name into the subclass. You have to define it as thus:
public abstract class A
{
public virtual string GetName()
{
return null;
}
}
public class B : A
{
//assume there are some defined properties.
public new string GetName()
{
return FirstName;
}
}
I'd recommend that you think of the abstract override approach:
public abstract class A
{
public abstract string GetName()
}
// to override
public class B : A
{
//assume there are some defined properties.
public override string GetName()
{
return FirstName;
}
}
this would be quite different. I would strongly recommend that you just override the abstract method in the subclass.
However, here's a quick ref on the subject (old but a good read):
http://www.akadia.com/services/dotnet_polymorphism.html

1) Is it really necessary to define a method as virtual if it has no
implementation? Surely it can just be overwritten in the subclass
without the use of virtual and override?
You can use an abstract methods, that have no body, but they if you derive from that class you must to override that method. All abstact methods have to be overriden in child class.
2) If (1) is incorrect, am I right in thinking that every virtual
method must be overridden in the subclass using it....
No, instead, you can use a virtual keyword to have an implementation inside that, but do not making override in a child class mandatory. Gives you more flexibility, from that point of view.
Usauly they use abstract to create rigid constrains for childs, so every child derived from it must implement specified member of base class.

That's exactly the difference between a virtual and an abstract method:
A virtual method can be overridden by derived classes if the choose to. A virtual method may or may not have a default implementation for inheritors to call into, which is done using the base keyword.
An abstract method must be overridden by derived classes. Its constraints are:
It can only be defined in an abstract class.
It cannot have an implementation, since it's up to the inheritors to define its behavior.

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?

Inheritence in C# question - is overriding internal methods possible?

Is it possible to override an internal method's behavior?
using System;
class TestClass
{
public string Name { get { return this.ProtectedMethod(); } }
protected string ProtectedMethod()
{
return InternalMethod();
}
string InternalMethod()
{
return "TestClass::InternalMethod()";
}
}
class OverrideClassProgram : TestClass
{ // try to override the internal method ? (doesn't work)
string InternalMethod()
{
return "OverrideClassProgram::InternalMethod()";
}
static int Main(string[] args)
{
// TestClass::InternalMethod()
Console.WriteLine(new TestClass().Name);
// TestClass::InternalMethod() ?? are we just screwed?
Console.WriteLine(new OverrideClassProgram().Name);
return (int)Console.ReadKey().Key;
}
}

I think you've got something confused here. There is an actual keyword "internal", is this what you want?
internal string InternalMethod()
{
return "TestClass::InternalMethod()";
}
But I think what you're really looking for is the "virtual" keyword. This allows you to do an override:
Parent Class
protected virtual string InternalMethod()
{
return "TestClass::InternalMethod()";
}
Child Class
protected override string InternalMethod()
{
return "TestProgram::InternalMethod()";
}
Using the "new" keyword is valid, but it completely reimplements the method. I.e. it breaks polymorphism.
Edit:
Here's a link.

In Java everything is virtual unless it is static/final. In C# you have to explicitly declare an instance method as virtual and then that method cannot be private. This article explains why.
By default all members of a class are private, so if you do not provide an access modifier (other than private of course) the InternalMethod() method in your example is private and cannot be virtual and thus cannot be overridden.
You must change it's access modifier and mark it as virtual and in the child class you must override it for the code to work the way you want it too.

This may not answer your question, but just to add a cent.
Internal denotes that types or members are accessible only within files in the same assembly. They are public to the assembly but having access slightly less than the public in actual.
MSDN Access Modifiers,
A common use of internal access is in
component-based development because it
enables a group of components to
cooperate in a private manner without
being exposed to the rest of the
application code. For example, a
framework for building graphical user
interfaces could provide Control and
Form classes that cooperate using
members with internal access. Since
these members are internal, they are
not exposed to code that is using the
framework

Try using the override keyword ... the new keyword is to call a class constuctor

Sure, it's possible, but in order to override a method, the method needs to be virtual or abstract, same as any other visibility.
class Base
{
internal virtual void Foo()
{
Console.WriteLine("Foo from Base");
}
}
class Derived : Base
{
internal override void Foo()
{
Console.WriteLine("Foo from Derived");
}
}
When you use the new keyword, it's called method hiding, which is not the same thing. If I write this:
class Base
{
internal void Foo()
{
Console.WriteLine("Foo from Base");
}
}
class Derived : Base
{
internal new void Foo()
{
Console.WriteLine("Foo from Derived");
}
}
static void Main()
{
Base b = new Derived();
b.Foo();
}
Then it will execute the Base Foo method, not Derived. In other words it will print Foo from Base. In the first case, it would still have executed the Derived method and printed Foo from Derived.