静态方法继承的正确替代方法是什么？

I'd say the best thing to do is to create a virtual/abstract Initialise method on the fruit class which must be called and then create an external 'fruit factory' class to create instances:

public class Fruit
{
//other members...
public abstract void Initialise();
}


public class FruitFactory()
{
public Fruit CreateInstance()
{
Fruit f = //decide which fruit to create
f.Initialise();


return f;
}
}

Why not create a factory class (templated) with a create method?

FruitFactory<Banana>.Create();

Move the factory method out of the type, and put it in its own Factory class.

public abstract class Fruit
{
protected Fruit() {}


public abstract string Define();


}


public class Apple : Fruit
{
public Apple() {}


public override string Define()
{
return "Apple";
}
}


public class Orange : Fruit
{
public Orange() {}


public override string Define()
{
return "Orange";
}
}


public static class FruitFactory<T>
{
public static T CreateFruit<T>() where T : Fruit, new()
{
return new T();
}
}

But, as I'm looking at this, there is no need to move the Create method to its own Factory class (although I think that it is preferrable -separation of concerns-), you can put it in the Fruit class:

public abstract class Fruit
{


public abstract string Define();


public static T CreateFruit<T>() where T : Fruit, new()
{
return new T();
}


}

And, to see if it works:

    class Program
{
static void Main( string[] args )
{
Console.WriteLine (Fruit.CreateFruit<Apple> ().Define ());
Console.WriteLine (Fruit.CreateFruit<Orange> ().Define ());


Console.ReadLine ();
}
}

I would do something like this

 public abstract class Fruit() {
public abstract void Initialize();
}


public class Apple() : Fruit {
public override void Initialize() {


}
}


public class FruitFactory<T> where T : Fruit, new {
public static <T> CreateInstance<T>() {
T fruit = new T();
fruit.Initialize();
return fruit;
}
}




var fruit = FruitFactory<Apple>.CreateInstance()

The WebRequest class and its derivative types in the .NET BCL represent a good example of how this sort of design can be implemented relatively well.

The WebRequest class has several sub-classes, including HttpWebRequest and FtpWebReuest. Now, this WebRequest base class is also a factory type, and exposes a static Create method (the instance constructors are hidden, as required by the factory pattern).

public static WebRequest Create(string requestUriString)
public static WebRequest Create(Uri requestUri)

This Create method returns a specific implementation of the WebRequest class, and uses the URI (or URI string) to determine the type of object to create and return.

This has the end result of the following usage pattern:

var httpRequest = (HttpWebRequest)WebRequest.Create("http://stackoverflow.com/");
// or equivalently
var httpRequest = (HttpWebRequest)HttpWebWebRequest.Create("http://stackoverflow.com/");


var ftpRequest = (FtpWebRequest)WebRequest.Create("ftp://stackoverflow.com/");
// or equivalently
var ftpRequest = (FtpWebRequest)FtpWebWebRequest.Create("ftp://stackoverflow.com/");

I personally think this is a good way to approach the issue, and it does indeed seem to be the preffered method of the .NET Framework creators.

First of all, not having static initializers that can be virtual doesn't mean you can't have "standard" member methods, that could be overloaded. Second of all, you can call your virtual methods from constructors, and they will work as expected, so there's no problem here. Third of all, You can use generics to have type-safe factory.
Here's some code, that uses factory + member Initialize() method that is called by constructor (and it's protected, so you don't have to worry, that someone will call it again after creating an object):

abstract class Fruit
{
public Fruit()
{
Initialize();
}


protected virtual void Initialize()
{
Console.WriteLine("Fruit.Initialize");
}
}


class Apple : Fruit
{
public Apple()
: base()
{ }


protected override void Initialize()
{
base.Initialize();
Console.WriteLine("Apple.Initialize");
}


public override string ToString()
{
return "Apple";
}
}


class Orange : Fruit
{
public Orange()
: base()
{ }


protected override void Initialize()
{
base.Initialize();
Console.WriteLine("Orange.Initialize");
}


public override string ToString()
{
return "Orange";
}
}


class FruitFactory
{
public static T CreateFruit<T>() where T : Fruit, new()
{
return new T();
}
}


public class Program
{


static void Main()
{
Apple apple = FruitFactory.CreateFruit<Apple>();
Console.WriteLine(apple.ToString());


Orange orange = new Orange();
Console.WriteLine(orange.ToString());


Fruit appleFruit = FruitFactory.CreateFruit<Apple>();
Console.WriteLine(appleFruit.ToString());
}
}

One idea:

public abstract class Fruit<T>
where T : Fruit<T>, new()
{
public static T CreateInstance()
{
T newFruit = new T();
newFruit.Initialize();  // Calls Apple.Initialize
return newFruit;
}


protected abstract void Initialize();
}


public class Apple : Fruit<Apple>
{
protected override void Initialize() { ... }
}

And call like so:

Apple myAppleVar = Fruit<Apple>.CreateInstance();

No extra factory classes needed.

All these ideas compensate for a glaring lack of language with stilted language constructs.

If I want an apple, I don't call a method on the fruit. Why should I even learn the family tree of the class? And I don't want to repeat myself or copy constructors through the whole hierarchy like a madman. Computers were invented to save me from such nonsense.

Two languages that have noticed and are now doing it right are PHP and Swift. Both supported static inheritance and covariance.

And old holy OOP books with a supposedly pure doctrine you can burn, because everything that allows me elegant code and compiles is good.